Breaking AV Software

@FRug

"Stefan: "Provide me with SOMETHING or you are not part of the solution."
Joxean: "No, i don't care because Oracle's been a meanie."
Hungry Man: "I like running in circles, why don't you?""

He was provided with everything he needs. Want to talk about running in circles? Read his posts. The last one is the first time he's posted *anything of substance whatsoever* - everything else has been whining that someone broke software he worked on and didn't just hand it over. Every other post reads like marketing drivel.

Sorry that I understand offensive research and take offense to having someone who actually participates in the security community being accused of malicious action.

God forbid companies take proactive approaches.

 

Okay, I do have to ask: are there good reasons for not enabling ASLR on all processes when available? The performance impact should probably not be significant, compared to the total overhead of an antivirus.

Right, ProcExp shows integrity levels.

There's an older sandboxing mechanism though - the restricted token, as implemented in RunAS on Windows 2000 and XP:
http://blogs.msdn.com/b/aaron_margosis/archive/2004/09/10/227727.aspx

I don't believe that will show up in ProcExp. And while it's quite useless for sandboxing a browser, it might be just the thing for sandboxing the parts of an AV engine that don't need filesystem access.

 

I disagree. If I tell you "Ubuntu has a several serious issues" would you run in circles reviewing tens of millions of LOC until you found something? In each source version ever committed? Maybe even in all GNU code because you do not know whether i understand what's part of the Kernel, GUI, components or 3rd party code? Or would you expect me to provide a hint as to what I have found? And how would you know that IF you found something was what i meant and when you can stop running after this particular bug? Or if I even judged this correctly and didn't bungle up during my analysis? That is the equivalent of a panic reaction with not even the slightest chance of success or even any proof of success. You think the Linux community would take me seriously or even waste a minute on someone so uncooperative? No. They would call me out and ask for contribution to the solution. And neither would ANY software company with more than a few thousand LOC of production code, i guarantee you that.

What is being done here is non-disclosure. Not even (ir)responsible disclosure. It is a claim that cannot be proven true or wrong by anyone except the finder. Existance cannot be proven. Solution or fix cannot be proven.

It is unproductive and not in the best interest of ANYONE affected or involved.

To be honest, even though STRONGLY favor responsible disclosure, even providing this as a zero day without prior notification would have been more helpful towards a timely solution that benefits users than this. This is more of a zero-day CLAIM, i don't even know whether there is an official wording for this.

Such as this, it is a waste of everyones time and nothing is achieved.

Now you're seriously trolling. Any proactive approach, code reviews (internal or external), pen-test, fuzzing or other means cannot guarantee the absence of an issue. It merely shows you didn't find any. That is an accepted truth for ANYONE working professionally in that area, and if you ever worked with a professional pen-tester that is what they will tell you on the first page of their report.


The right thing to do would be to provide information so there can be a fix and effective countermeasures can be taken in future versions to a specific type of issue. That is what is the common behavior of either responsible or (ir)responsible disclosure. But at least SOME kind of disclosure. Anything else serves no useful purpose.


As it is, even if the WHOLE code would be rewritten from scratch, by different people, you still wouldn't be able to prove there has been an improvement to the claimed issue.

 

@FRug: I can actually see both viewpoints here...

Researcher: "The AV company wanted me to do my job for free. And the public needed to know that the product was vulnerable, even if it was too dangerous to reveal the full details of the vulnerability."

AV company: "The researcher indicated the existence of a serious vulnerability, and then asked for money to reveal more about it. We consider this extortion."

And reviewing this thread I'd personally side with the researcher. Not sure what the law says about that where I live, but to quote one celebrity: "We don't base our morality on the law."

 

It probably depends on what you're after. I've even been using some of Joxeans tools occasionaly, so I am not against his work in general, but honestly believe giving AV vendors a chance to fix things wouldn't cost him any additional effort that he hasn't already freely invested for the fun of it. But he obviously isn't interested in that, for whatever reason he may personally have for that, i just feel it isn't helping anyone. Not even himself, i mean he's basically barring himself the chance for future contract work with vendors.

 

Besides, he's not only pointing out specific vulnerabilities, but also a lack of security measures that the majority of AV's do not use:
-Even the most well known exploit migitations, DEP and ASLR are not used or not on all files.
-Even if these are enabled for all files, there are still other migitations that can be used.
-Use only the privileges necessary for a certain action instead of always the highest privileges.
-Analyse/open files in a sandboxed process.
-Drop/disable old/useless code.
-Bug bounty
etc.

 

Yes I agree with BMW. General advices at the end of presentation are IMO more important for AV industry than specific vulnerabilities.

hqsec

 

That's what i mean with depending on what you're after. This is more on the lines of recommending more widespread adoption of certain technologies for mitigation. A whole different thing imho than disclosing a specific vulnerability as most of these are meant for hardening or reducing the effect of a vulnerability, not about fixing it. Having an unknown and thus "unfixable" (note the quotes) bug is not _solved_ by reducing the potential impact with above mentioned techniques.Which doesn't mean it isn't interesting to consider at least some of them.

I read the paper a while before this discussion started, so I might be missing some parts of it in what i remember. But to me it was even unclear whether some of the mentioned bugs in different AVs where something that was even directly connected with his current research or historical, previous things he had found which may or may not still apply.

 

@FRug

Did you read the research? There was nothing particularly vague about it. He didn't go "You have issues" he detailed and outlined the issues and even provided a tool to find and demonstrate direct vulnerabilities.

If you wrote a piece of research that details multiple design and architectural flaws in Ubuntu and you even included multiple POC against specific parts of the OS (easily analogous to the currently discussed research) you would absolutely get taken seriously...

You've misunderstood if you think the only step here is to try to find those vulnerabilities. Half of the paper is dedicated to explaining why these vulnerabilities are consistently present, and why they're so specific to AVs - that should be addressed. Naturally everyone should be running that fuzzer against their products anyways to find the vulns he's discussing, but that's not nearly as big of an issue as what the research is really pointing out.

And his decision not to disclose is a very common one. Not everyone feels that they should hand over research to multi million/billion dollar corporations for free. I won't get into an ethical discussion about this because I think it's pointless, the point should be that his research shows pretty nicely a lot of issues with AV and the vulns are just a fun demonstration of this.

Look at Sophail. The issue was not the few vulnerabilities, though those were obviously critical to fix, the issue was that an Antivirus was injecting privileged content into unprivileged content, allowing for escalation even in sandboxed environments.

Same thing, but the vulns weren't handed over.

"Having an unknown and thus "unfixable" (note the quotes) bug is not _solved_ by reducing the potential impact with above mentioned techniques."

Those techniques very explicitly deal with those vulnerabilities. That's the point of techniques like ASLR / SSP/ DEP, to not have to know the vulns ahead of time, to generically make them harder to attack.

 

Yes i did read the paper/talk.

I quote his paper:
"For that talk I did fuzz/test the following ones: BitDefender, Comodo, F-Prot, F-Secure, Avast, ClamAV, AVG."

All other AVs mentioned in it have none of the things described regarding them apart from one slide mentioning the names plus the half-sentence level of detail Stefan has criticized, some even have a small hint at where he found something, some have nothing at all.

The time frame for finding most of the bugs seem to have been July/August last year. So relevancy to todays releases is also unknown. That's what happens if communication of results are delayed for such a long time. Most if not all AVs have done major product updates since then.

No they don't. They limit the damage, or chance of damage (i.e. crash-for-every-10th user only). They do NOT deal with the underlying bug in a satisfactory manner. Having all these enabled would still require to find a fix for each particular issue, at least if you are taking this seriously. Making something harder to attack is very much desirable, don't get me wrong, but is not a fix.

The general investigation of techniques and researching their use on your product is one thing, but fixing a bug (maybe just locating and changing a single letter in one out of millions of lines of code) is another, and i think this is the main point where you and Stefan are just talking about very different things and do not understand which point exactly the other is trying to make.

One thing is a strategic, mid to long term action. The other is usually short-term, but requires detailed information or in the best case the ability to reproduce the problem, otherwise this is a nearly hopeless undertaking with truly large code bases. And this second part cannot be avoided even if the first has been done perfectly.

Maybe this helps you understand my POV better.

 

@FRug

How can you read it and say "All other AVs mentioned in it have none of the things described regarding them apart from one slide mentioning the names plus the half-sentence level of detail Stefan has criticized, some even have a small hint at where he found something, some have nothing at all. "

He details issues that are universal to all programs and all AV.

"The time frame for finding most of the bugs seem to have been July/August last year. So relevancy to todays releases is also unknown. That's what happens if communication of results are delayed for such a long time. Most if not all AVs have done major product updates since then."

Architectural updates? I'd be shocked.

"No they don't. They limit the damage, or chance of damage (i.e. crash-for-every-10th user only). They do NOT deal with the underlying bug in a satisfactory manner. Having all these enabled would still require to find a fix for each particular issue, at least if you are taking this seriously. Making something harder to attack is very much desirable, don't get me wrong, but is not a fix."

More like one every 4,294,967,296 to one every 18446744073709551616 users, without a further vulnerability and with a few slightly positive assumptions.

Certainly not one every 10th user gets a crash.

Naturally you should still patch. That goes without saying. But these things force attackers to come up with multiple vulnerabilities and not just one.

"The general investigation of techniques and researching their use on your product is one thing, but fixing a bug (maybe just locating and changing a single letter in one out of millions of lines of code) is another, and i think this is the main point where you and Stefan are just talking about very different things and do not understand which point exactly the other is trying to make."

If you focus only on the POCs and vulnerabilities it's easy to get distracted. But the first part of the paper is dedicated to fundamental and abstract issues.

"One thing is a strategic, mid to long term action. The other is usually short-term, but requires detailed information or in the best case the ability to reproduce the problem, otherwise this is a nearly hopeless undertaking with truly large code bases. And this second part cannot be avoided even if the first has been done perfectly."

He provides the tool to do it with. If they fuzz with it and find nothing they're welcome to mention this to everyone. But I very much doubt they'll be talking about major architecture changes.

 

Many of them are very implementation and product specific. Universal certainly does not fit in here. Frequent maybe yes.
A finding worth mentioning, certainly.

Some may be artchitectural, some aren't. ASLR and DEP is in most cases a choice to use a newer compiler and runtime environemnt, and potentially dropping compatibility. Not something to do quickly in many cases (changed runtime, differing function set, changed APIs in case of MS especially, testing, 3rd party components, incompatibilities when using different runtimes resulting in an or or nothing choice, testing, beta...) , but not necessarily an architectural change either.

That is VERY os and fault specific because it depends on many factors. Random external quote (first i found, I am not having at lot of time just now:

"By itself, ASLR is not a 'silver bullet' defense, but the inclusion of ASLR in addition to other security functions such as DEP (Data Execution Prevention) and the security aspects of UAC (User Account Control) help Vista to defend itself against many threats that would work on Windows XP and other prior operating systems. In Windows Vista, there is a 1 in 256 chance that a given threat will be rendered powerless. " (By Tony Bradley, CISSP-ISSAP)

And yes i notive that he's mentioning DEP to make that much better _overall_, but it may still be irrelevant to a fault. Still the 1/256 was what I was aiming at from reading up on it years ago.

On the other hand i would be terribly surpised if clam av had profited from any of the mentioned techniques with the mentioned inifinte loop (remotely exploitable denial of service in case of a mail-server for example). That class of defect, as an example, is almost always due to logic errors in the parsing of intentionally or unintentionally corrupted files. Haven't looked at the specific vulnerability though. May do so for the fun of it if details are public.

Again, two different things. Strategic choices vs. Bug-Fixing. It's not about focusing on only one in my opinion.

That's an opinion you are entitled to have. If indeed architectural changes are required for some AVs and some of the affected components, that is at least mid to long term though. User's could be helped by a fix of vulnerabillities now.

 

@FRug

"Many of them are very implementation and product specific. Universal certainly does not fit in here. Frequent maybe yes.
A finding worth mentioning, certainly."

A significant portion is things like "This is what attack surface is" "This is how an AV becomes remote attack surface" "This is how you get root" etc. Not specific to anything, really. He just points out that it applies to AV.

"Some may be artchitectural, some aren't. ASLR and DEP is in most cases a choice to use a newer compiler and runtime environemnt, and potentially dropping compatibility. Not something to do quickly in many cases (changed runtime, differing function set, changed APIs in case of MS especially, testing, 3rd party components, incompatibilities when using different runtimes resulting in an or or nothing choice, testing, beta...) , but not necessarily an architectural change either."

No, ASLR/DEP would not be architectural. I mean the actual structure and behavior of the program. I very very very much doubt any products have taken significant steps here.

""By itself, ASLR is not a 'silver bullet' defense, but the inclusion of ASLR in addition to other security functions such as DEP (Data Execution Prevention) and the security aspects of UAC (User Account Control) help Vista to defend itself against many threats that would work on Windows XP and other prior operating systems. In Windows Vista, there is a 1 in 256 chance that a given threat will be rendered powerless. " "

Naturally my numbers were assuming a few things:

1) Perfect entropy - doesn't exist
2) A layout where each structure can be spaced equally
3) Full address space usage

Not to mention it ignores segmentation in memory.

But the chances are very small, and in later OS's significantly more than 1/256.

In reality a proper implementation is still in the hundreds of thousands for finding a value in the stack. Much higher than 256 - I assume that has to do with the fact that vista only made use of 8 bits of entropy when it first implemented ASLR.

"That's an opinion you are entitled to have. If indeed architectural changes are required for some AVs and some of the affected components, that is at least mid to long term though. User's could be helped by a fix of vulnerabillities now."

I'm sure they could. What I resent is calling the research "FUD" and accusing the author of malicious intent. He makes entirely valid points, which he backs up.

 

Guess most things have been said and we're back to opinions and views from different angles. I see no need for further discussion as it will possibly not lead to changed stances or new insights on the subject.

 

Works for me.

 

This is a true pity that enough $'s would not give you change of heart.

You obviously have a skill-set that practically all of them would benefit from since they are somewhat lacking in code auditing but also i suspect your foo goes well beyond just code auditing.

Maybe one day , net up for the legal pay day and not the public lolz

PS @ Stefan, you have summed up what is wrong with the industry, you get paid for what you do then why not pay a man for the work he has done especially if it improves your product.Its a no brainer really... Avast is the only company that got it dialed.

Yah needs to recruit talent where ever it has roots and not send it packing with added insults.

Talent is talent regardless of it hat(s) and lets face it most have egos or quirks...

 

I think you misunderstood. He's saying he does not write malware - he is not a bad guy. He's a good guy, he works for legal pay.

 

Latest free version, guard see pic

 

The DLL in question appears to be a resource-only DLL. It does not contain any code that could be targeted by an exploit.

 

Thanks for the explanation

 

In the PDF slide 45, the author shows the DLLs under that BD Service, which BTW is running bdcore.dll 11.0.1.6. As of this posting, it's 11.0.1.12. Anyhow...

Here's a screenie of the same for the Lavasoft AdAwareService, permanent DEP & 64 bit ASLR, in the current v11.2 Personal Security. That licensees build to their own tunes is understood, I can't help but think that by now BD's current apps should present the same.

 

Malware Can Evade Antivirus Code-Emulation Feature
http://news.softpedia.com/news/Malware-Can-Evade-Antivirus-Code-Emulation-Feature-453506.shtml

 

ITA. Also another, which is trying to be/do too many things at once. It's not just about the "bloat", but thinking they can produce a security software, do its QA, eliminate its vulnerabilities all at once. Considering quite a few of them are slow, buggy or glitchy, I don't find it too hard to believe they've utterly failed at the last one. Not to mention complaining about ego or shady practices all the while lacking the humility and integrity to even consider that those people might have a point is grade-A hypocrisy. They should at least follow Avast, Eset or F-Secure's example.