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 …

[Anonymous Coward]

Happened before

Same thing happened with version 8 in 2008, but it was out of its support period.

[The Mighty Spang]

eh?

gotta be something else or something bloody stupid. "2010" > "2009" in string comparisons. only perhaps if they were comparing "0" with "9" will they have a problem.

[Pablo]

is required.

How can it be so hard to correct something like this? It should be a one-line fix unless their date handling is incredibly sloppy. Though the fact that this bug happened at all kind of suggests that it is.

[Anonymous Coward]

Which string compare function?

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.

[gollux]

Bzzt! Wrong!

Why we tossed Symantec products 6 years ago...

[David Heffernan]

Errors in article

2009 is less than 2010 under string compare since in position 3 you have 0 which is less than all other digits. I presume the string compare was working on 9 and 10 in which case the latter is less than the former.

[Christian Briddon]

No surprise

This is no surprise. SEP is a bug ridden turd that performs badly and is annoying to use. The only reason we use it is because we are forced to.

[Ken Hagan]

Left as an exercise for the reader

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.

[Frank Zuiderduin]

String compare

Rediculous. How can any string compare function see 2010 as earlier than 2009?

[Mike Shepherd]

"If there's one thing I've been telling customers...

...it's "Don't switch to another product"

[Dinger]

Symantec Bug Fix Imminent

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!!

[TeeCee]

Now that should have happened.....

Just out of interest, when was the update dated?

[Alan Esworthy]

Not only ridiculous..

...the offered explanation is also preposterous (in that word's original sense).

[Anonymous Coward]

Just as glad I dropped them years ago

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.

[Rune Moberg]

false sense of security

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)

[Citizen Kaned]

of course not...

script kiddies are little linux users. they wouldnt want to infect their OS with virii would they? :)

[Ian Wellock]

Evolution is to blame

Now we know what happened to the Mayans; they evolved into Symantec.

Obviously it was a lesser branch of Mayan culture that favoured 2010 as the end of the calendar rather than 2012, but still...

[John Smith 19]

One of Microsofts's lesser know subsidiaries

I beleive they are still part of the MS empire.

But this is p&*s poor work. Should have been caught in testing (actually they should not have hired a programmer who would *make* that kind of mistake).

[Stoneshop]

Why the hell are they coding their own date compare functions?

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

[Sureo]

Hard to fix?

@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.

[Spudders]

title required...answers on a postcard

SEP 11.0 i have at work is now working ok - was knackered until that point however.

Not usre why they could not support 2010 date the issues over the other peoples "2016" would have been down to maybe a Hex issue - as 10 in hex is 16

[TallPaul]

It's not just Symantic ...

... last week SpamAssassin was scoring email dated 2010 as "in the future" (generally a good indicator of spam). The initial "fix" has to change the regular expression such that the bug will come back to haunt us in 2020!

[Anonymous Coward]

Is this issue not related to the othe year 2.01K problems?

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.

[Citizen Kaned]

symantec ffs

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?!?!

[Simon B]

PMSL!!!

PMSL, people use Symantec products still?! PMSL ROFL!!! Don't people learn? ROFL ROFL ROFL.

[Estariel]

SEPM was rebadged from....

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...?

[Ammaross Danan]

Answer to a question

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)