Browser security report by Secunia

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

 

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

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

 

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

 

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. 1) Scripting disabled. When you see this in the code...
   
   
   Code:

   <script>
   

   ...you know that the exploit requires scripting in order to work.
   
   
2. The browser must permit the file to download without a prompt.
   
   
   
3. 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:

1. Scripting disabled
   
   
2. File downloads w/o prompt
   
   
3. No outbound firewall protection to block calling out for the trojan download
   
   
4. 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

 

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,

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:



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:







The PDFfile loads in FireFox:




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:



Same file as I downloaded last evening:

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

 

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

 

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




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:






----
rich

 

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

 

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.

 

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.

 

Same here.....

 

Thanks Mrk for confirming one of my biggest gripes: software imposing its own settings w/o user permission.

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:

​

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:

​

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:

​

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

 

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

 

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

 

From CNET, which was summarizing a Symantec Press Release:

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

 

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:

​

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.

​

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

 

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!

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