Browser security report by Secunia [Archive]

Newby

April 16th, 2009, 10:20 AM

Arup,

You are a knowledgeable member. You have posted the thread http://www.wilderssecurity.com/showthread.php?t=236526&highlight=Arup in which the winning hacker in an interview said that Chrome was the hardest to hack (see http://www.wilderssecurity.com/showpost.php?p=1428411&postcount=9), also in another post a Standford University study is mentioned which states that Chrome will be less vlnarable to exploits (http://www.wilderssecurity.com/showpost.php?p=1341118&postcount=29).

Another member posted this test, but http://nsslabs.com/anti-malware/browser-security, but I found that it was funded by Micorsoft: http://www.thetechherald.com/article.php/200912/3268/Can-you-trust-the-NSS-Labs-report-touting-the-benefits-of-IE8

It seems that 95% of the Wilders Members are in favour of FF, but you have to cripple it so much, it has just a little bit more functionality than a text based browser (I can't recall but according to Bellgamin the safest browser).

Kees1958 his opinion seems to be that Chrome (or Iron/Chromium) is the safest browser available at the moment. I noticed that he was told to POQ (which is an insult when I look it up at the Dictionary) when he hinted to a FF fan to switch to Chrome when using Sandboxie.

So here I am noting that a lot of undefended claims are stated at Wilders regarding the FF security, on the other hand I have a Hacker, Standford and a massive poster voting for Chrome and another very experienced security expert (Ilya of DefenseWall) and a experienced massive poster (you) voting for Opera.

You are one of the few brave members who dare to state that FF lags behind for over a few years. Now you are saying that Opera is the safest, could you explain that a little better (I think because exploits are fixed very quickly). I also found a post of the programmer of DefenseWall who thought that Opera was the safest browser at the time of posting. So I am not questioning your statement, just asking for explantion.

The previous post links to a blog which discusses an exploit. The exploit also summerises its succes against browsers (see pic), IE7 leads (nearly 5000 times succes, FF nearly 2000 succesfull exploited, Opera 200 times and Chrome 160). When you take the market share of IE into account http://en.wikipedia.org/wiki/Usage_share_of_web_browsers then the rating would be IE 75, FF 90, Chrome 122 and Opera 285) so that looks bad for FF, considering the fact that a study prooved that FF users are normally technical savvy and use a lot of security add ons.
Thanks EDIT mistake

EDIT: thanks for the PM, this clarifies a lot :thumb:

Eice

April 16th, 2009, 10:32 AM

-{ Quote: "Another member posted this test, but http://nsslabs.com/anti-malware/browser-security, but I found that it was funded by Micorsoft: http://www.thetechherald.com/article.php/200912/3268/Can-you-trust-the-NSS-Labs-report-touting-the-benefits-of-IE8" }-
No offense, but do you really believe that all it takes to dictate the outcome of a report is to fund it?

Eice

April 16th, 2009, 10:35 AM

-{ Quote: "The previous post links to a blog which has an exploit. The exploit also summerises its succes against browsers (see pic), IE7 leads (the early 5000 times succes, FF neraly 2000 succesfull exploited, Opera 200 times and Chrome 160)" }-
You have the numbers wrong btw. First column represents total hits, second column represent # of successful exploits.

Also, please do not take that report as representative of browser security.

Newby

April 16th, 2009, 10:53 AM

-{ Quote: "No offense, but do you really believe that all it takes to dictate the outcome of a report is to fund it?" }-

No but you can influence it by agreeing on the study prerequisites, scope and hypothesis, before signing the funding. I am definitely not a Newby on that field of expertise.

Newby

April 16th, 2009, 10:56 AM

-{ Quote: "You have the numbers wrong btw. First column represents total hits, second column represent # of successful exploits.

Also, please do not take that report as representative of browser security." }-

Sorry, I have corrected this, you are right. No, there are to many aspects. That is what I am trying to understand, but the outcome now makes sense to me. Just found it nice that you also dared to question the general believe at Wilders that FF is the best and stated it with a sample.

Thanks

Eice

April 16th, 2009, 10:58 AM

-{ Quote: "believe me, I am definitely not a Newby on that field of expertise" }-
Don't worry, it just makes it all the easier for me if you already understand this. ;)

-{ Quote: "No but you can it influence by agreeing on the study prerequisites, scope and hypothesis," }-
Then that means the study is valid only within the specified scope of research, of course.

As stated, the NSS Labs study tests the ability of browsers to blacklist social engineering sites that deliver malware, and from what I can tell, it would seem that IE8 had the best ability to do so.

Whether this translates into IE8's security in general with all other factors was not tested, and cannot be determined via the methodologies and results of this study alone.

Newby

April 16th, 2009, 11:07 AM

-{ Quote: "Don't worry, it just makes it all the easier for me if you already understand this. ;)

Then that means the study is valid only within the specified scope of research, of course.

As stated, the NSS Labs study tests the ability of browsers to blacklist social engineering sites that deliver malware, and from what I can tell, it would seem that IE8 had the best ability to do so.

Whether this translates into IE8's security in general with all other factors was not tested, and cannot be determined via the methodologies and results of this study alone." }-

The outcome is more or less congruent with other indicative fact finding. As questioned by me in that thread, the difference between IE7 and IE8 are striking. So some of the new features of IE8 (smart screen and XSS filter) must have contributed to the succes. IT-wise Chrome and IE8 have chosen different roads to security improvement. Marketing wise they both have an advantage (XSS, smart screens URL analysis versus Sandbox) , it just comes in handy that the biggest got better no need to worry, so customers stay in your seats please, Even then, I think the majority of the customers won't take the trouble of installing a different browser for technical or security superiority, so discussion on this topic will be limited to 25 percent of the Windows based PC users maximum.

Thanks again

Fly

April 16th, 2009, 04:14 PM

-{ Quote: "Why hollow?

How many people using FF got infected through their browser? 0.
How many people keep getting infected using IE, no matter which version? > 0.

Mrk" }-

Come on !

You can't really believe that !

I presume you're not comparing FF on Linux vs. IE on Windows ? That's not a fair comparison.

'How many people using FF got infected through their browser? 0.'
There is no way you can back that up. Say, whay if a FF user is not using noscript plus that adblock thing, are they really safe from malicious scripts ? ::)
Or what if they get (too many) dangerous add-ons for FF ?

IE 7 can be reasonably safe if you don't fall for the concept of 'trusted zones' (I've never needed them), increase the security settings, and use software (AV or otherwise) that monitors (attempted) changes to IE, and if you generally know what you are doing.

Mrkvonic

April 16th, 2009, 04:58 PM

I'm talking Windows, FF vs IE.

Say, what if a FF user is not using noscript plus that adblock thing, are they really safe from malicious scripts?

The answer is: yes.

I'm waiting these last 3 years for one person to show me ONE example of a successful drive-by in Firefox (or Opera, for that matter).

So far, EVERY single, EVERY single explout ever shown and demonstrated was on IE. In FF, you may get a prompt to download file, at best. Now, downloading files and executing them ... that's a different story altogether.

But ONE example where you can actually do something malicious with FF. No one has shown me EVER.

IE CAN BE SAFE. That's not in dispute. But we're talking default levels.

Now, number of vulnerabilities means absolutely NOTHING. Why? Crude example: let's say a software X has 4 million local vulnerabilities, software Y has 1 remote. And which one do you think is more severe?

I don't care if FF has 300 or 7 trillion reported bugs found, it means nothing. As long as problems are solved quickly, everything is fine. Vulnerabilities that are patched are no longer vulnerabilities, are they?

Quick patch cycle, auto-update, you can't beat that.

Just a reference, do you know how many software and system bugs I reported in the last 6-7 months that you won't read about anywhere? The numbers mean nothing.

Once again, I IMPLORE, BEG and TEASE, one example of a drive-by in Firefox, I'll buy you icecream for a year. Hell, I'll buy an iPhone.

Besides, it's innocent until proven guilty. Crying that FF is bad is ok. But show me example.

Go to any HijackThis or spyware forum. Who do you think posts those logs and begs for help? FF users? Nope. IE users. With FF, you don't get drive-bys. What remains is pure deliberate user-initiated execution, but that equals suicide, for all that matters.

I'm not a fanboy or anything. I believe Opera is the same in this regard. And so is K-meleon and many other browsers. None supports local scripting or activex. That's all. The entire magic.

Mrk

Rmus

April 16th, 2009, 09:38 PM

-{ Quote: "Say, what if a FF user is not using noscript plus that adblock thing, are they really safe from malicious scripts?

The answer is: yes.

I'm waiting these last 3 years for one person to show me ONE example of a successful drive-by in Firefox (or Opera, for that matter)." }-This is certainly true for those that exploit a browser vulnerability.

However, the script can trigger other actions that enable the running of an executable, as has been demonstrated with PDF and DOC file explolits, where the user is redirected, or in using Google, gets to a malicious web site with this code:

<head>
<script>
document.write('<iframe src="somefile"></iframe')
</script>
</head>

where the document is loaded and opened.

Using Opera in your example with scripting enabled, I set up a simple test with that code in an HTML file, using a MSWord document which opens and runs a macro to load a DLL which starts an instance of IExplorer:

207966

You can emphasize not to use MSWord or remove IExplorer, configure the browser to prompt for ALL files, keep scripting disabled, use another PDF Reader, etc. But nonetheless, using your scenario of scripting enabled, a user not taking those precautions can be victimized, so that some protection to block the payload would seem to be in order:

207967

Real DOC and PDF exploits embed or call out for a malicious executable.

Many other ways exist to prevent executables from installing, of course, and I emphasize this because I don't think it's wise to consider the Browser impenetrable, because there are opportunites for exploitation if a user forgets to disable scripting, changes other settings, etc.

Advanced users, probably not. But who knows?

In this case, it is not an exploit of a Browser weakness, rather a script making use of a legitimate Browser function (i-frame in this case).

REFERENCE

Hosted javascript leading to .cn PDF malware
http://isc.sans.org/diary.html?storyid=6178

----
rich

Mrkvonic

April 17th, 2009, 02:10 AM

Thanks for the example. I would appreciate the script code.

Still, please try this example:

Place the html file on a server and then open it in the browser. And then try to open a file that resides on the server - as is the case in drive-bys.

You will see that Opera / Firefox will prompt you for a download. You won't get the file opened, you'll get a prompt to open/save.

I just did that and here are the results:

207981

Iframes, javascript and whatnot.

Cheers,
Mrk

Rmus

April 17th, 2009, 04:06 AM

OK, I'll run the test from a server.

I would bet that most users have their browser open documents directly.

This is the HTML code:

<head>
<script>
document.write('<iframe src="hmmapi.doc"></iframe')
</script>
</head>

207984

Let's look at a current PDF exploit in the wild. I would venture to guess that most people use Acrobat Reader and make use of the Browser plugin.

Here is the exploit code (redacted):

SCRIPT language="javascript">

function PDF()
{
for (var i=0;i<navigator.plugins.length;i++)
var name = navigator.plugins[i].name;
if (name.indexOf("Adobe Acrobat") != -1)
{location.href = "spl/pdf.pdf"
}
PDF()
</script

wepawet analysis of the PDF code:

Shellcode and Malware:

....d.d...2.d..d
...2d.d.*..-....
..http://XXXXXX.cn/XXXXXXXXXXX/exe.php

...

MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit)

This is a redirect from a legitimate site; the exploit runs upon connection to the malicious site:

207986

-{ Quote: "File load.exe received on 04.17.2009 08:39:38 (CET)
Sunbelt 3.2.1858.2 2009.04.17 InfoStealer.Snifula.a (v)
" }-Now, no one I've helped would be hit by either of these exploits because I configure Opera to prompt for all file types, so that even in a remote code execution (drive-by) exploit, you get a prompt:

207985 207988

Of course, we know that standard procedure should be to have the Browser Prompt to download files: But do you think all users are aware of this? You do, and you advocate using Foxit Reader, but how many "Mr.and Mrs. Smiths next door" do?

So that is my argument, that you cannot depend on the Browser to be impenetrable in the hands of everyone. There are just too many variables, too many settings, add-ons, ad nauseum.

And so, in answer to your challenge:

-{ Quote: "I'm waiting these last 3 years for one person to show me ONE example of a successful drive-by in Firefox (or Opera, for that matter)." }-I give you two. Thanks for the offer of the rewards, but I'll decline since I prefer homemade ice cream, and have no use for an iPhone.

----
rich

Mrkvonic

April 17th, 2009, 04:39 AM

Rmus, your example is valid provided the browser is set to open files automatically. But this is not the case, both for Firefox or Opera, by default.

By default, both these browsers prompt for download. So you have to go one step further and make files open automatically, which is no different than executing them yourself.

207989

BTW, we agree on security. I don't count on the browser to do things. I count on this: double-click, it runs, no double-click, it does not run. As simple as that.

I'll send you some ice-cream via email ... I hope it doesn't melt on the way.

Cheers,
Mrk

Rmus

April 17th, 2009, 11:49 AM

-{ Quote: "By default, both these browsers prompt for download. So you have to go one step further and make files open automatically, which is no different than executing them yourself." }-That may be for the latest version of Opera. I'll check that. I installed the older v8.5 on my laptop and PDF is configured to use the Plugin:

207997

At first the exploit would not work because I normally have Plugins disabled:

207998

By the way - one other requirement was necessary for this particular PDF exploit to work: No outbound firewall monitoring. As the file opened, I got an alert:

207999

I had to permit the connection for the download to attempt.

-{ Quote: "BTW, we agree on security. I don't count on the browser to do things. I count on this: double-click, it runs, no double-click, it does not run. As simple as that." }-Yes, it is simple. But I never assume anything with people. I'll wager that many people think the browser is supposed to "do things" without any input. I know that this is true with those I've seen who use IE.

That's why it's necessary to get down in the trenches and help the clueless when we can and show them these things.

I've never had a problem making people understand basics. Using screenshots is a big help: a visual image registers in memory better than just a list of "thou shalt nots." This is especially effective with the WinAntiVirus exploits where a fake scan may pop up.

-{ Quote: "
I'll send you some ice-cream via email ... I hope it doesn't melt on the way." }-Thanks! Zip it using FreezerWrapZip.exe. I'll be waiting...

----
rich

Fly

April 17th, 2009, 03:54 PM

A lot of tech talk ...

I'll ask it in a simple way: is it possible for FireFox (let's exclude zero-day vulnerabilities for the browser) in its default configuration, to encounter on a website malicious javascript that downloads a trojan ?

It's possible in IE. Would FF ask if you wanted to download or install the trojan ? ???

yeow

April 17th, 2009, 04:31 PM

With outdated Java Runtime Env (JRE) installed, I've the impression that Smitfraud may silently install with IE/FF/Opera. Not too sure, but I think so.

Mrkvonic

April 17th, 2009, 05:07 PM

-{ Quote: "A lot of tech talk ...

I'll ask it in a simple way: is it possible for FireFox (let's exclude zero-day vulnerabilities for the browser) in its default configuration, to encounter on a website malicious javascript that downloads a trojan ?

It's possible in IE. Would FF ask if you wanted to download or install the trojan ? ???" }-

You would be asked to download. Or open the file. It would not run by itself.
Mrk

Eice

April 17th, 2009, 11:54 PM

-{ Quote: "I'll ask it in a simple way: is it possible for FireFox (let's exclude zero-day vulnerabilities for the browser) in its default configuration, to encounter on a website malicious javascript that downloads a trojan ?" }-
No browser ever does this by design. If it does, it's called a bug, and fixed.

That said, have a look at the list of known vulnerabilities (http://www.mozilla.org/security/known-vulnerabilities/firefox30.html) for Firefox 3. That page lists 19 fixed vulnerabilities listed as "critical", which in Mozilla's own words means that the "vulnerability can be used to run attacker code and install software, requiring no user interaction beyond normal browsing". Firefox vulnerabilities are mushrooming lately, with yet another security fix release scheduled on April 21st, so yes, the answer to your question is that: it's very much possible.

-{ Quote: "It's possible in IE." }-
You need to stop basing your claims on 3-year-old data.

Arup

April 18th, 2009, 12:32 AM

If comparisons are being made, IE8 should be in contention, not a old unpatched IE7.

Rmus

April 18th, 2009, 12:44 AM

-{ Quote: "A lot of tech talk ... " }-I will summarize.

Exploits on the web attack:

the browser

plugins/applications

For browser exploits, as Mrk has stated many times, there are none in the wild against FF or Opera. Vulnerabilites surface, as they do in dozens of applications and are fixed. All code has the potential for misuse.

For exploits using plugins/applications, I gave two examples using remote code execution (drive-by).

The first using a MSWord file has three requirements in order to be successful:

1) Scripting disabled. When you see this in the code...

<script>

...you know that the exploit requires scripting in order to work.

The browser must permit the file to download without a prompt.

No protection to prevent trojan executables from successfully installing.

This exploit can be blocked if any one or more of those three requirements are not satisfied.

The PDF exploit had four requirements:

Scripting disabled

File downloads w/o prompt

No outbound firewall protection to block calling out for the trojan download

No protection to prevent trojan executables from successfully installing.

This exploit can be blocked if any one or more of those four requirements are not satisfied.

The other way of using malicious files is to send them by email. But that is a different scenario.

----
rich

Rmus

April 18th, 2009, 12:56 AM

I received an email earlier today from a friend. She had run a couple of my tests in Opera last evening to confirm. She looked at this thread, and wrote, You should download FireFox and do the tests. I said that Mrk already had. No, he did not post a screenshot for PDF. I just downloaded FF and it loads PDF, she said.

OK.

Mrk wrote earlier,

-{ Quote: "Rmus, your example is valid provided the browser is set to open files automatically. But this is not the case, both for Firefox or Opera, by default.

By default, both these browsers prompt for download." }-I don't find this to be the case. I just downloaded the latest version of FF, and as in Opera, files are associated with the Plugin or application in Firefox:

208017

OK, lets look at this still live PDF exploit again. Remember, originally the user is redirected from a legitimate site. That site has been sanitized, so I'm connecting directly to the malicious site where javascript code calls for the PDF file:

208024

208023

The PDFfile loads in FireFox:

208021

At this point FireFox is out of the picture. Acrobat Reader connects to the server that hosts the trojan, load.exe; it attempts to download and is blocked by execution prevention:

208020

Same file as I downloaded last evening:

-{ Quote: "File load.exe received on 04.17.2009 08:39:38 (CET)
Sunbelt 3.2.1858.2 2009.04.17 InfoStealer.Snifula.a (v)" }-

So, Firefox behaves with this exploit as did Opera. This is by design since the four necessary requirements are met as indicated in my previous post. Except I stopped the exploit at step 4 so I wouldn't get infected!

People can argue that you would not be susceptible to this exploit because you disable scripting, or any of the other three requirements.

But I hope you see my point that you cannot assume that all users would have everything configured for maximum security, meaning that you cannot assume that any browser is impenetrable in all user cases.

Remember, this is not a browser exploit, rather an Acrobat Reader exploit. The browser just facilitates bringing the PDF file into play.

----
rich

Mrkvonic

April 18th, 2009, 02:24 AM

I'll install Acrobat on a test machine and check. I'll do it for FF and Opera.

BTW, as to Opera + PDF, I get the same as my .doc screenshot.

Cheers,
Mrk

Rmus

April 18th, 2009, 03:17 AM

In looking at the Options in FF I see that "Show Downloads Window" is set by default.

208029

However that seems to be overridden by Applications Preferences, which made the PDF file load in FF, as shown in my previous post.

But If I change the Action to "Always Ask" then I get the Download Prompt when connecting to that malicious site:

208030

208031

----
rich

Mrkvonic

April 18th, 2009, 06:11 AM

Hello,

rich, this is exactly what I got in the first test case I did several posts ago.

Now, I done some more testing; I've tested twice and got two different results:

On my regular machine (No Acrobat, only Foxit):

Default Opera 9.64 does not open pdf files, suggests download (shown above).

On my test machine (Acrobat newly installed, Foxit):

Opera opens the pdf file using the adobe plugin. It turns out that when I installed Adobe Reader, it set itself as the default browser and overwrote the default settings. Very audacious I might say. If I change the associations for pdf files to Foxit, then it prompts for download.

I guess the problem is with the PDF software, not browser.

This means several different results for different browsers, different PDF software. I don't know what to make of this.

If we're talking about semantics, then yes, in certain circumstances, as you've shown, the browser can be used to trigger a third-party application, which then might be used to try an exploit. But this necessitates the presence of such software and right (wrong) browser settings.

On the other hand, this is not a browser issue in the same sense that activex are exploited in IE.

The question is: can you trigger a system call / system dll / system function that is pure Windows through Opera or Firefox. My observations show this to be: no.

Cheers,
Mrk

Fly

April 18th, 2009, 07:48 AM

Not to argue, but:

(The quote system here has its limitations, so I'll cut and paste)
'Quote:
Originally Posted by Fly
I'll ask it in a simple way: is it possible for FireFox (let's exclude zero-day vulnerabilities for the browser) in its default configuration, to encounter on a website malicious javascript that downloads a trojan ?'

'No browser ever does this by design. If it does, it's called a bug, and fixed.'

IE was obviously not intended to serve as a means to infect people !
I use IE 7, above average/normal security settings, fully patched.
Yet, at some time in the past 12 months a piece of malicious javascript (JS/Wonka?) tried to download a trojan. My McAfee detected the script and in real-time prevented the installation of the trojan. I presume that without security software the trojan would have been installed.
I'd call it a vulnerabilty, not a bug.

If someone here can convince me that with increased security settings for IE (without disabling scripting) drive-by infections by malicious scripts are impossible, I'll happily ditch all my security software, except something for on-demand scans when needed.

'Quote:
Originally Posted by Fly
It's possible in IE. '

'You need to stop basing your claims on 3-year-old data.'

It happened to me with IE 7 in the past year.

Eice

April 18th, 2009, 08:02 AM

-{ Quote: "IE was obviously not intended to serve as a means to infect people !" }-
Yes. I wasn't trying to be condescending; sorry if it seemed that way.

To explain your situation with McAfee: running across an exploit script doesn't necessarily mean your browser is vulnerable to it. It could be targeted at an older browser version, or you may already be patched against the vulnerability the script is trying to exploit. The antivirus doesn't know that, of course, and it's job is to block everything can recognize. But the point here is that just because you ran into an exploit script, doesn't necessarily mean you'd have been pwned if your antivirus wasn't running.

I won't try to convince you that drive-by infections are "impossible", but I'll say that they're rather improbable if you keep yourself fully patched. Also, if you use IE on Vista, Protected Mode + DEP + ASLR all but guarantee against infection via drive-by downloads, though again I won't say it's 100% impossible.

I personally browse "naked" using IE8 on Vista with Protected Mode, and I feel completely safe doing so.

Kerodo

April 18th, 2009, 10:33 AM

-{ Quote: "I personally browse "naked" using IE8 on Vista with Protected Mode, and I feel completely safe doing so." }-
Same here..... :thumb:

Rmus

April 18th, 2009, 12:07 PM

-{ Quote: " It turns out that when I installed Adobe Reader, it set itself as the default browser and overwrote the default settings. Very audacious I might say. " }-Thanks Mrk for confirming one of my biggest gripes: software imposing its own settings w/o user permission.

-{ Quote: "
I guess the problem is with the PDF software, not browser.

This means several different results for different browsers, different PDF software. I don't know what to make of this.

If we're talking about semantics, then yes, in certain circumstances, as you've shown, the browser can be used to trigger a third-party application, which then might be used to try an exploit. But this necessitates the presence of such software and right (wrong) browser settings." }-I will re-emphaze your point, that the PDF exploit above is not a browser exploit.

This is easy to confirm with firewall prompts. The first connection out to the site is with the browser:

http://www.wilderssecurity.com/attachment.php?attachmentid=208024

After the PDF file is loaded into Firefox, Acrobat Reader takes over the functions and calls out for the trojan. I showed that code in a previous post:

208049

Because Acrobat has no mechanism for prompting, the trojan happily downloads and installs, unless something else intervenes at this point.

If Firefox or Opera had attempted to download the trojan, an automatic prompt for an executable would have displayed.

You can see the cleverness in using applications and plugins to trigger the malware, rather than the browser . We've seen, in addition to PDF, exploits against Flash, Quicktime, Real Player, etc. Mebroot (the MBR exploit) uses many IE specific vulnerabilities and an array of application/plugin vulnerabilities, hoping to catch a user of an alternate browser with scripting disabled, an unpatched application (Quicktime, etc) or no execution prevention protection.

The malware writers are very clever. Upon being redirected to their site, code instantly identifies the browser and delivers the appropriate exploit.

To demonstrate: using the same URL for the above exploit, if using IE6 unpatched, you are served with the MS06-014 (MDAC) exploit which attempts to download the same load.exe file:

208047

208048

Same payload, different trigger mechanism. This is a browser exploit in contrast to the PDF exploit for Opera and Firefox. I hope everyone understands the difference.

By the way, Before testing this exploit, I knew all the specifics about the payload, etc, from the analysis in the sans.org diary I referenced in an earlier post. So, I knew what to expect.

Back to applications/plugins:

It behooves the user to make sure that any such applications in use have their specific files configured in the browser preferences to "Always Ask" or "Show Download Dialog."

I do not depend on any settings in the application to be secure. Acrobat has a setting to disable displaying in the browser. That might change if the user updates, or installs a newer version where the settings get reset.

Even back in Win9x days before these types of exploits, we always stressed not opening files on the web directly. Rather, download first, then open in the application. Once the browser takes control of a file, you have lost control of it without other specific safeguards in place.

----
rich

Mrkvonic

April 19th, 2009, 05:12 AM

So what do we tell a casual reader who's not in the mood to go through 20+ posts?

Do we tell them their operating system is at fault, browser, third-party applications? Except for default-deny strategy, we are dealing with several different scenarios here, depending on the application/browser setup.

Cheers,
Mrk

ravnen

April 19th, 2009, 06:39 AM

-{ Quote: "
After the PDF file is loaded into Firefox, Acrobat Reader takes over the functions and calls out for the trojan. I showed that code in a previous post:" }-This is just great info, thanks.
Can you say anything about your test system.
I have tried to test it, but im not able to load the trojan, when the pdf is loaded in FF or if I download the pdf and execute it.

My setup:
VMware guest - XP SP3 + Fully updated + LUA + SRP + newest FF.
Adobe Reader 8.0/9.0

I have taken the newest link from malwaredomainlist.com.

Thanks,

/Jesper

kriebly

April 19th, 2009, 07:35 AM

-{ Quote: "I'm talking Windows, FF vs IE.
I don't care if FF has 300 or 7 trillion reported bugs found, it means nothing. As long as problems are solved quickly, everything is fine. Vulnerabilities that are patched are no longer vulnerabilities, are they?

Quick patch cycle, auto-update, you can't beat that.
" }-
From CNET (http://news.cnet.com/8301-1009_3-10218666-83.html), which was summarizing a Symantec Press Release (http://www.symantec.com/about/news/release/article.jsp?prid=20090413_01):

===
Safari had the longest window of exposure between when the exploit code was released for a vulnerability and when a vendor released a patch, with a nine day average, while Mozilla had the shortest with a less than one day average. Mozilla browsers were affected by 99 new vulnerabilities in 2008, followed by 47 in IE, 40 in Safari, 35 in Opera and 11 in Google Chrome. There were 424 browser plug-in vulnerabilities and ActiveX accounted for most of those.
===

Ouch. I guess the general advice against ActiveX has aged well.

Rmus

April 19th, 2009, 01:00 PM

-{ Quote: "So what do we tell a casual reader who's not in the mood to go through 20+ posts?" }-I would summarize this way.

This exploit needs to pass through 4 steps to succeed:

1) Scripting must be enabled. At this point, this exploit is no different from any other web-based exploit that needs scripting enabled to run, and will fail on any browser with scripting disabled.

2) The PDF file must be able to load into the browser or open directly into the Reader. Browsers block executable files by default, but some seem to associate the action of some files with the application or plugin. In setting up Opera for people, I've always pointed this out, and we look in the FileType Preferences to change these actions. This has been always been a policy with me not so much as a concern for this type of exploit, which wasn't around in earlier times, but to have control over opening files on the web. Some people like to scan files before opening, for example. I want to be in control of everything, as much as possible.

Here is Opera's configuration for PDF. You can see the various options available:

208107

With application exploits on the rise, I hope browser developers will consider having all file types prompt for action by default, because I'm sure that many people are not aware of how all of this works in the background. In this exploit, a prompt for action would alert the user that something is not right: the user is not expecting a PDF file.

3) Acrobat must be able to connect out to the internet to download the malware. A Firewall with outbound monitoring will prompt for an application not already permitted outbound access. Of course, Acrobat should not be permitted free access to the internet.

http://www.wilderssecurity.com/attachment.php?attachmentid=208049

This, of course, doesn't come into play if the user doesn't have firewall outbound monitoring.

4) The trojan payload must be able to install with nothing in place to block download/installation of unauthorized executables. In my view, this is the most important step to secure, since any of the above three precautions can be neglected/changed inadvertantly. A type of fail-safe, if you will.

Running as non-Administrator; Software Restriction Policies; many other solutions exist to Deny by Default the malware payload from automatically installing.

From the way I've set up security for people, this exploit is not a threat.

I did not read the Secunia Report. From the example image in the first post, I assume the report is similar to others that present statistics on vulnerabilities, which I find of no use. It's a diversion from more important work. I can make better use of my time by watching for analyses of exploits in the wild, and following vendor advisories regarding patches/updates.

----
rich

Rmus

April 19th, 2009, 01:01 PM

-{ Quote: "I have tried to test it, but im not able to load the trojan, when the pdf is loaded in FF or if I download the pdf and execute it." }-Evidently you are using a version of the Reader that is patched against the particular PDF exploit you found, so the code won't run.

This one I tried is the first I've found that will execute using my version 6 of the Reader. There are many different PDF exploits targeted against various versions of the browser - just look at the Adobe advisory page to see how many they have patched!

-{ Quote: "Can you say anything about your test system." }-It's not a test system, rather my main system. I don't test malware in the sense of letting it execute. I'm just interested in seeing how these web-based malware exploits can be prevented. Normally I read about the exploit before trying it. They always have the same payload: a malware executable, which, with your setup, would be easily blocked at the gate!

----
rich