Anti-Virus Rife with Vulnerabilities
Sergio Alvarez and Thierry Zoller of nruns gave an interesting presentation at Hack.lu 2007 on vulnerabilities in anti-virus software (hat tip: Pauldotcom podcast Episode 93, 1:21). One of the main problems is anti-virus software takes in just about every file format and attempts to parse and process it. If the software developer makes a mistake in this parsing it can lead to a vulnerability. In the podcast, Paul mentions how coding errors in Snort and Wireshark parsing have also led to vulnerabilities.
Adding to the problem is AV software is a large attack surface, running on unmanaged code that has been reused, ported and adapted for years, and often developed with extreme time pressure. You know how fast those new AV signatures come out.
Sergio submitted 80 anti-virus vulnerabilities last year to a variety of vendors with about 30 being fixed to date. Interestingly the first common problem they list in slide 21 is “Communication Protocols Security by Obscurity”. Sound familiar? They also show some back and forth with vendors that highlight the risk of leaving vulnerability fixing and disclosure to the vendors’ discretion, even security vendors.
nruns also found over 800 cases in 20 different vendors of being able to bypass the anti-virus.
(read an article on the presentation or view the entire presentation)
Two SCADA security related points to this story.
1) Don’t rely solely on your security perimeter that by the way is increasingly trying to parse more protocols. Upon disclosing a vulnerability to a control system vendor we typically hear that this bad guy or traffic should never be allowed into the control system network to run the attack. Yes, the vendor is correct, but your firewalls with IDS/IPS and other technologies have vulnerabilities. Some have been found and many are waiting to be found. You need to be able to detect, delay and prevent attacks if an attacker or a worm has breached your perimeter.
2) Security needs to be an important part of the software development lifecycle from the start of code development. The only real fix, as discussed in the presentation and podcast, for many of these anti-virus vendors would be start over which is extremely expensive, but so is patching old code for an increasing number of vulnerabilities. There are so many parallels here to control system application code based. Buying a new SCADA or DCS application? Understand the basics of the security development lifecycle; require the vendors to provide their security development lifecycle processes; and demand to see evidence that they are implementing these processes. Unfortunately we may be in a situation where there is not a good answer from any of the respondents, which will only change through the asset owner pressure of the purchase decision.
Author: Dale Peterson
Posted: January 7th, 2008 under Anti-Virus, Security Vendor.
Comments: 7
Comments
Comment from sheik
Time: January 7, 2008, 9:39 pm
AV is just one layer in DiD (Defence-in-Depth). Presenter thinks that all other layers will be mime during the malicious attack is going through. The base for their argument is that AV can lead to compromising the OS and compromised OS will be used for further attacks as a base. But, there are IDS/IPS (Network & Host-based) and Firewalls (Network & Host-based), from different vendors and nearly impossible to wade through without a alerts. So, it will be a very difficult fight, but do not forget the purpose of DiD - to make it difficult for the penetrator as much as possible (the most disliked word to the hacking community is “impossible”) and get him tired. In Security parlance, determined hacker can get through protection, but it depends on how long the determination lasts and the value of the efforts. DiD is kind of Risk Management, and not a 100% fool-proof protection.
Comment from Ralph Langner
Time: January 8, 2008, 5:31 am
Interesting topic, Dale, especially since many asset owners rely on AV as their only countermeasure.
Comment from Jake Brodsky
Time: January 8, 2008, 8:24 am
Ralph, you’re assuming they have any countermeasures installed in the first place.
Anything is better than nothing. We are in the process of installing antivirus software despite having turned off the autorun features, and despite having no internal or external e-mail, text messaging, or web service. Those are by far the most common vectors for virus software. Eliminating them leaves far less room for common viruses to attack.
Are we immune? No. I know there have been more than a few viruses that have used the anti-virus and OS firewall software itself as a vector. We have to choose these things with care.
The key thing to consider is how much effort is it going to take to develop a wide variety of OS, hardware, and software that we can still maintain. This speaks toward the availability issue. If we can’t get things back together in some form at any hour of the day or night or we simply don’t have the mental bandwidth to juggle all these different breeds of software and hardware, then we’re no better off. Our availability hasn’t improved. Our reliability will suffer. and at the end of the day, that’s what matters to an industrial control system manager.
Comment from Ralph Langner
Time: January 8, 2008, 9:49 am
Jake, here is what my experience tells me. At some point in time asset owners realize that they have a security problem (mildly put), if only by information from their IT department. Then they realize that this problem is hard to come by. They determine that they can’t subdivide the network as they don’t have the time and knowledge, and not even the required protocol details in the first place. But instead of doing nothing, there is hope in the form of AV solutions. The nice thing about this is that it appears you can buy security as a product — well, why not believe what the vendors tell. Deploy, and make sure your AV signatures are updated timely, perhaps by a direct link to the Internet. Now as we learn from the nruns presentation, your network may even be less secure than before. So is anything really always better than nothing? Probably not.
Comment from Ron Southworth
Time: January 8, 2008, 10:12 pm
Ralph I would agree with Jake with respect to this topic. I will go a bit further with some more general challanges and observations from my experience here.
For my money if the virus activity has found it’s way on the control system and has not been discovered at the entry point the battle is already over for control systems. Availability being the key driver for that statement. For control systems we need virus prevention not cure model of managing the risks.
Jake I have had AV running here for over 5 years on our “non isolated” and isolated systems using AV software on the HMI and server computers regardless of OS.
We have created exceptions for the software we use so that it does not scan directories or files that can be adversly affected and have modified its default values to perform deep analasys very infrequently and to do it at low risk times of the day. We had a number of issues early on with file sharing / processor load considerations and these crop up from time to time along with a host of other problems that i won’t put out in open forums.
Jake I will gladly send you an email on some of the pitfalls if you have not already uncovered them yet, knowing you though I would say you would be able to teach me some things I have not had the time or inclination to discover.
For the record we do have problems with the AV software taking up more CPU time than it should. The Manual updating of virus signatures and testing of the virus updates etc is a huge human resource burden.
To be honest I think the Anti Virus model used in the “traditional environment” we have to use at present is worse that having an active virus or several virus problems on the system at times.
I remember a scruffy chap fresh from his computer degree saying to me that his idea for his personal future personal success was to create a need and then fill it. This chap now owns a antivirus company that is doing quite well.
I beleive we need to see developed an approach that is different from the standard products and delivery methods we are using now and involves a perimiter detection, protection, and prevention model.
I know there are some control systems products that are surfacing that are following this path so I don’t think my idea is too off the wall.
I think we need to start looking with our lateral thinking caps with control systems security, certainly we should learn from the lessons and successes of the other sciences and levrage cots products where we can. However how we handle zero day issues in the long run needs a different model it needs to be proactive on the entry point of the perimiter.
Comment from amino world
Time: January 9, 2008, 2:04 pm
the whole AV ‘culture’ is flawed — we can’t possibly enumerate all of the bad things — and something we have to use in the interim between moving from applications developed in the default allow era to applications developed in a default deny era. oddly enough, during this (supposed) transition we also get ‘wireless modbus on the web’ products… so we may not be making any progress after all.
still, what we’d like most is _not_ to run AV software. let’s not lose sight of that goal and press suppliers to provide products and designs that don’t need this kind of drag (ie AV software) on resources.
Comment from Ron Southworth
Time: January 9, 2008, 9:00 pm
Sounds like a logical step forward but a daunting target to acheive.
Write a comment