Symantec Y2.01K bug still stymies customers Nine days after Symantec's corporate antivirus dashboard succumbed to an end-of-decade bug that caused it to stop accepting updates, the company has yet to fix the underlying problem, much to the chagrin of customers. In a case of extreme Déjà vu, the flaw in SEPM, or Symantec Endpoint Manager, stems from its inability to …
This post has been deleted by a moderator
Unless it was only looking at the last digit, then it would have sorted 2010 before 2009 (0 < 9.) Or doing something like
string year1 = "2009";
string year2 = "2010";
bool valid = false;
for (int i = 0; i <= 3; i++)
{
valid &= year1[i] >= year2[i]
}
Then 2 >= 2 is true, 0 >= 0 is true, 1 >= 0 is true, but 9 >= 0 is false, so it would fail.
I have never come across a string compare function that says
("2010" < "2009") == true
However, all string compare functions that I have come across say
("10" < "9") == true
It looks like the old Y2K problem, combined with a string compare. If they'd implemented just the Y2K bug, they'd have been fine until 2100.
Devise "a string compare function that interpreted 2010 as being earlier than 2009", given the additional constraint that it presumably must also give 2008 < 2009 and 2009 = 2009. (The latter constraint precludes simply returning a random result, which must by now be what Symantec's customers believe was happening.)
Oh, wait, I've just figured it out. They're reading the dates from right to left, so we have ...
0102 < 9002
8002 < 9002
etc
...so if Symantec's customers just sit out the next decade, they'll be fine come 1 Jan 2019. OK I'm kidding, but you have a go. Just *how* can you write a string comparison with the behaviour claimed by Symantec?
A far more likely explanation is that the bug gets all year comparisons wrong, or simply ignores years, but was written within the last 12 months and released without even the most elementary "new year" testing. As a result, the bug is seen for the first time on customer systems on a day when all the developers are on holiday.
I received an email from Symantec last night to say that a fix to the Y2.01K bug would be released via LiveUpdate over the weekend. Apparently there will be no requirement to do anything with systems as the update will be applied by LiveUpdate and will correct the issue.
We'll have to wait and see if this is really true!!
They off-shored all their support and forgot about programming and installation reliability. I was forever having problems with their stuff killing itself and their only answer was "uninstall and re-install". now that might have been interesting if their uninstall worked the way it should have worked, but it never did. Their "clean-up" program didn't clean out all the old crap from various folders and the registry so cleanup and uninstall never worked right. the final straw was right after i renewed my subscription to their crap service and a couple of weeks later an update killed it. that was the end and i've never looked at it again.
This post has been deleted by its author
I needed/wanted to run a suspicious looking executable. I used ESET to manually scan it. It found nothing. Later when I scanned the trojan this executable unpacked, again it found nothing.
It was my own fault for trusting the virus scanner, yes. But had I not had a virus scanner, I would have been a helluva lot more careful.
Adding more code (with potential security holes of its own) surely is not the way to go as far as protection is concerned. Padding exploits is the only recourse.
Oh... I better upgrade to Linux, because surely there is no such thing as mysterious trojans there... Is there? (the way some Linux-heads act, it would be natural to assume this to be the case)
That's what libraries are for. And who the hell handles dates as strings except for displaying?
I did some coding back when a 286 was a top of the line machine, and 20MB was the harddisk you got in one (if you had the cash). For space reasons date storage was confined to 2 bytes: 5 bits for days, 4 for months, 7 for years with 1900 as the base year. And with the day in bits 0..5, etc, you could simply compare dates (insofar that was necessary, most was just date stamping) as unsigned words. Worked just right. Later we went with modified Julian date (because date comparisons, and especially date distances became relevant), which took four bytes. Just a few lib functions to convert to and from Julian. Date calculations are easy as pie that way.
If Symantec is reinventing that wheel, they're total fuckers. But we knew that already
@Pablo - poor/sloppy design, implementation and documentation can make problems like this difficult indeed to resolve, as any developer can attest. Not to mention the lack of proper testing which let a bug like this get out to the customers. Big FAIL for Symantec.
@AC - "uninstall and re-install" is the go-to response for many (all?) support desks, even when you tell them you already did it with no benefit. Apparently there is no plan B. Another Big FAIL to them, along with my undying contempt.
While I'm sure the information above is useful, is the root cause not similar to the other year 2.01K problems reported already?
The underlying issue has been data stored as BCD - when 9 changes to 10, all of the integer compare functions stop returning the expected result.
the it manager i took over from had specced up symantec for Av and backups.
i cant wait for their licences to expire to get something better in. SEP is utter shite.
of course backup exec is having problems too - some hotfix was issued just before xmas to fix a fudge they previously made. meaning no full backups over the xmas period. what a company!
their old AV (at my last company) was crap too. it wouldnt let us remove some virii as they were processes. apparently their AV couldnt stop a process for some reason?!?!
As I recall, the product labelled SEPM v11 was actually bought from a competitor rather than developed inhouse.
So any comments on the date coding would be more properly addressed towards acquisitions due diligence than towards an endemic coding issue within Symantec...?
There are several people assuming a string-comparison of a date as "2009" should < "2010", but there are several programming languages that have multiple date-comparison functions built in. VBA (if you've ever worked in M$ Access databases) has a string-to-date type function that has a cut-off date around 1910 or so. So, if you put in "10/20/25" it would translate out to 20 Oct 1925, but if you put "10/20/05" it would translate out to 10 Oct 2005, instead of 1905. If Symantec's lib function translates "01/01/10" to 01 Jan 1910, instead of the expected 2010, it could be a date interpreter and NOT the comparison function that is the root cause.
Just a thought.
FAIL (but I'll let you decide for who)
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
