14 antivirus apps found to have security problems Organisations should get their antivirus products security tested before deployment because the technology across the board dangerously elevates attack surfaces, COSEINC researcher Joxean Koret says. COSEINC is a Singapore security outfit that has run a critical eye about 17 major antivirus engines and products and found 14 …
This post has been deleted by its author
This post has been deleted by its author
Don't blame the C language please. Despite its age it is still an excellent language, it still has relevancy and it is the language of choice for most safety critical systems. The issue here is poor developers and/or their pointy-haired managers.
Its true that C does contain some (few) functions that are inherantly unsafe (and impossible to make safe - see 'gets') however these should be well known to all developers for these applications and are also easily caught with analysis tools. Most of these functions are also deprecated and obsolete under the ANSI C standard too. Just dont use these functions.
That is why various guidelines and standards have been developed to make coding safer:
http://en.wikipedia.org/wiki/MISRA_C
www.stroustrup.com/JSF-AV-rules.pdf
Whatever language you use, you can screw up, but C/C++ just gives you a more direct way of doing so. Safe code is hard to do and needs some skill and the willingness to stick to the above guidelines and to USE the tools already out there to check for errors and bad practice.
Buggerate is the one that gets me. Admittedly, from Urpeons who learned English from American TV.
When I first encountered the use of the verb 'to bugger' instead of 'to bug', I corrected them... But having a senior colleague stick their head in a meeting and ask if they can buggerate someone for five minutes had me banging my head on the table, and said someone replying that the meeting was nearly done and could they bugger them when they were free almost had me on the floor.
Don't blame the C language please. Despite its age it is still an excellent language, it still has relevancy and it is the language of choice for most safety critical systems. The issue here is poor developers and/or their pointy-haired managers.
Quite.
"AV engines were often built in C which led to vulnerabilities like..." suggests the flaws are caused by the chosen language. The language used doesn't directly lead to vulnerabilities. Sure it doesn't hold your hand and it will let you you stupid things. You're expected to be able write decent code. Shouldn't be unreasonable to expent competent coding from company providing security software.
I think there is plenty of blame to go around. C/C++ for having some inherently dangerous constructs and doing very little to discourage their use "for legacy reasons". AV companies for writing sloppy spaghetti like code, a lot of which is bound to be very low level and very fragile. OS manufacturers for still needing AV software even in a day and age when a lot of checking could be pushed into the cloud and mitigated by virtualization and other tricks to prevent malicious code doing bad things. And users for doing dumb things that require AV software in the first place.
C/C++ for having some inherently dangerous constructs and doing very little to discourage their use "for legacy reasons"
I can do dangerous things with a knife or chainsaw - that doesn't make them bad or dangerous when used in a responsible manner.
This reports reads to me more as advocacy of certain approaches rather than anything substantial and completely ignores some key parameters. A/V is low level software and needs low level control - you are not going to write an A/V in VB after all. The second point conveniently ignored is the size of the runtime system. For C it's pretty minimal and interactions with the OS occur at defined points in the execution - easy to analyze, relatively easy to defend. With higher level languages you never really know - when anything at all could trigger e.g. IPC or a memory allocation.
That's without even considering external library issues: I see the inclusion of large external libraries has already indirectly been advocated below with the crap UI point - creating a fancy UI with e.g bare win32 API calls is a lot of work. The lack of those support libs is key to being able to validate code - for example any MFC based app leaks memory, as does any.NET app - it is unavoidable because the support libraries themselves do. If they can't even get that right who knows what security issues are lurking in them?
A keep it lean, keep it mean approach is the best approach and that is what really limits the exposure surface of the app, not following the whims of someone who has never written security software and has fallen for the marketing bullshit of the latest buzzword technologies.
"I can do dangerous things with a knife or chainsaw - that doesn't make them bad or dangerous when used in a responsible manner."
Sure. But plain old-fashioned C is a bit like a chainsaw with no chain guard. It's a capable tool, but you gotta watch where you put your hands...
Frankly, though, I think the responsibility lies with the AV vendors, not the tools they use. It's a poor workman who blames his tools. These folks are supposed to know about security, that's what they do.
I suspect the reality is that the "insecurity" of C has less to do with the language itself, and more to do with the underlying application code being written 10/15/20 years ago and not being looked at since. Even the best programmer back then couldn't be expected to foresee every security eventuality, and would have no knowledge of much of what is now considered best practice.
This kind of thing is always the risk you take when you focus on simply adding bits to existing applications and making it look pretty, rather than starting from scratch and writing the entire thing based on current best practice from the ground up. You might not be able to polish a turd, but some companies really will try! :-)
I suspect the reality is that the "insecurity" of C has less to do with the language itself, and more to do with the underlying application code being written 10/15/20 years ago and not being looked at since
I'd say it's mostly due to the code age but a fair amount is also down to the language. Although it's true that C/C++ code is not inherently unsafe it's also true that there's not a great deal of pressure within the language to dissuade you from unsafe practice and even less to encourage you to good practice. You can improve things a bit if your compiler supports 'treat all warnings as errors' but that's a choice you have to make and reliant on the verbosity of your compiler.
The good thing about both those languages (and I'll always have a soft spot for C++) is that they trust the programmer and allow them total control.
The bad thing about both those languages is that they trust the programmer and allow them total control.
C is a powerful tool in the hand of capable people. It's natural environment is UNIX and simple systems.
One should notice that good C programmers don't program complex things in C. This may sound paradoxical, but what they actually do is writing a small "interpreter" which interprets data structures containing the actual logic. Thus creating something like a domain specific language. C with its data and function pointers makes this very simple. This is the true strength of C.
Apparently that is not what people have been doing here, they literally programmed complicated things directly in C, making both their life unnecessarily hard and risking serious problems if they mess it up.
They do have a bad track record. I seem to recall one of the first bits of OS X malware actually targeted one of the first AV engines itself, rather than the platform it was supposed to protect.
Back on Windows, I was developing a system utility a few years ago. On the low level, you can either open files by filename (the usual way), or by file number - except doing the latter would cause a BSOD every time once the file was closed again, which I eventually tracked to a bug in the on-access scanner component of the AV product I was using. I didn't investigate much further at the time, but as I recall it was allocating a buffer *when files were opened by name*, then freeing that buffer when files were closed - whether that buffer had been allocated in the first place or not. There was probably something exploitable in there if I'd looked hard enough.
Then there was the time McAfee decided that Windows itself was malware and needed to be deleted, which made for a "fun" departmental cleanup day...
After a few random images, it prompts you to update java via pop up that takes you to a lookie-likey page. Not sure if the links to download are broken or what, but they point to: 'hXXp://secure.15-pn-installer.com which is not Oracle. so be aware!
(tweaked by mod to break the link so the hard-of-thinking don't go clicking it)
I did a quick scan of the pdf file and found no mention of Microsoft Security Essentials. Bearing in mind that it's likely to be used by quite a few Windows users, and I didn't get the feeling the article was aimed at only non-Windows AV, that seems to be a serious omission. Coupled with the pdf not having a decent structure, not listing all AV software tested, and not giving a properly laid out set of results for each AV product, and I'm afraid this whole examination starts to look woefully inadequate. Which is a shame, as it appears to be attempting to highlight valid shortcomings in AV products.
May of been something to do with this line....which TBH I think is a bit lame.
"The largest vendors weren't notified as they should be already dedicating their sizable resources to vulnerability research."
Phew thank goodness Oracle and Adobe are only little companies, because with that attitude, users of a bigger company's software could be in real trouble.
Just recently I've had to use other products the family computers as it seems that MS Security Essentials is getting less effective. I used to like the product as it was the only thing that didn't cripple the PC, and now I feel I should find another AV tool
I keep my PCs clean by not running AV software. You need to disable all the random scripting languages and crap using tools like NoScript and then your PC is more or less safe if you understand your operating system well enough to know the difference between something that is executable and something that isn't. The idea is to scrutinize the executables which you can do by finding online reviews etc and seeing what kind of people wrote them. Some tools are recognised in the industry as being very good so guess what I use them and my PC doesn't have any toolbars on it like yours does.
That's the craziest damn advice I've ever seen someone give. There are lots of non-excutable files that carry infection. Even a simple .rtf file can be a vector of infection (per CVE-2014-1761). Anything that gets loaded into another program (word, excel, index files, heck even .nfo files) can exploit buffer overflows and dozens of other vulnerabilities of their parent programs.
Nay, I would not abandon my A/V just yet.
My best advice for A/V these days is Webroot. I used to use ESET (and I'm a little upset to see them on "the list") but Webroot is solid like a rock.
Just my 2 cents.
Our company is a recent convert to Webroot and, I must say, it is an excellent way of ensuring your end users do not turn off AV ever, using tray icons and such. Also, it provides an easy central repository for monitoring all PCs protected under any given set of licences, and seeing infections and how they were dealt with. It picks up stuff Kaspersky never ever spotted too.
This topic has been boiling away for some time now. It was heightened recently when the CEO of Symantec / Norton admitted his products only worked some of the time.. So what are we to do?
I dedicate at least one or two legacy XP machines to banking and nothing else and place them on an isolated network. Same goes for critical work with a couple of boxes dedicated to running Win7... The remaining hardware, I save for YouTube / Flash crap and put them on their own branch to blow up without costing me a packet i.e. CryptoLocker...
But who has time for all of this really? What a waste, and a joy killer.... Still, what else can one do, retreat from the net entirely when you add in all the spying and tracking?
"Organisations should get their antivirus products security tested before deployment"
In my innocence not to say ignorance I had imagined that that would be standard practice and if it is not I confess myself astonished. My question is - if it is not regarded as best/standard practice, then why not?
Shoddy Quality... When it comes to software suddenly quality isn't important... The 'we can always patch it later' attitude....
WTF?
We should be able to sue software companies for shoddy releases... After all, hands up, who wants to buy a washing machine that leaks every other patch Tuesday.... Or a car that reboots during driving on the highway. Or a pacemaker or other critical medical device made by a software firm?
"Innocence?" - you have actually worked at an organisation!? Or got lucky ;-)
In my 30 years of experience, 95% of all organisations are incurably dysfunctional - in the "Lets take off an nuke the site from orbit. It's the only way to be sure"-way.
Organisations generally grow into caring only about themselves, the feral staff will smell this and adapt by producing those metrics that will generate Bonuses, Promotions (and Harming the Competition a.k.a. Colleagues.
So, "Anti-virus Installed on all PC's before random deadline" is perhaps a Metric, "Testing said anti-virus suite to see if it works and is secure" is "useless time wasting and procrastination for the IT-geeks own benefit", Rescuing the organisation from a virus attack is "Stepping up in a crisis", not having a virus attack in the first place becomes: "Lets outsource IT, those people are not doing any work that I can see"!
I did some work at a big chemical factory a while ago. During my safety training that was carried out by the on-site fire/emergency team (yep they had their own private fire station just in case) they told us that they had just been bought up by a venture capital group.
Apparently when the Venture Group's accountants went over the books they said -
"Hmm it seems since you've had your own on-site Fire/Emergency team, that you haven't had any major incidents or fires! So why exactly do we need you?"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
