[PCWorld]

Post your comments for The Ultimate Browser Security Test here

[IvanTech]

Most definitely Chrome. I use it all the time, more than any other browser.

[Resovolt]

Safari.

[redofromstart]

No, it does not beg the question. It raises the question. Please don't use cliches you don't understand -- although that would probably put blogging out of business.

[cmaurand]

All zones are dangerous, I don't see why security zones are required. Your network and the internet are dangerous places. All content should be treated as such, no matter the origin.
zones, schmones.

[cmaurand]

Oh, yeah. forgot to mention, the problem is ActiveX, not the browser.

[WinTard]

cmaurand said:

>All zones are dangerous, I don't see why security zones are required. Your network and the internet are dangerous places. All content should be treated as such, no matter the origin.
>
>zones, schmones.
>
>Oh, yeah. forgot to mention, the problem is ActiveX, not the browser.

I would disagree with you, I think the root cause to most problems sits between the chair and keyboard of any computer.

That said, one potential way to look at things might be that ActiveX is to IE what Javascript is to other browsers?

Please google:
Results 1 - 10 of about 737,000 for javascript vulnerabilities. (0.23 seconds)
Results 1 - 10 of about 805,000 for ActiveX vulnerabilities. (0.22 seconds)

Hmmm, similar in proportion, don't you think?

And why allow unknown ActiveX or unknown Javascript from unknown untrusted sources to run on YOUR system? They ARE after all unknown programs with unknown motives or intents...

That is presumably a finer level of granularity for security allowing such distinctions rather than a (One Size Fits All) which is never true in the real-world.

PS: I like Chrome, no contest.

[cmaurand]

Hmmm, similar in proportion, don't you think?
And why allow unknown ActiveX or unknown Javascript from unknown
untrusted sources to run on YOUR system? They ARE after all unknown
programs with unknown motives or intents...

I think they should be able to run, but shouldn't have access to anything on your machine except the viewer and whatever sandbox they should run in.

I whole heartedly agree that most problems arise with the users running in privileged modes.

The google search isn't very useful in this case. If you're going to search on vulnerabilities, you should do your search on the CERT website. google will have all kinds of hits from different forums, mailing lists, etc.

[techie4fun]

Or use good judgement when browsing the web.

[WinTard]

I agree with you on google searches, but with these simple terms, issues related to Javascript or ActiveX are similar in proportion from a comparative sense. Not from an absolute vulnerability number count.

Although Javascript isn't Java per-se, Java isn't a virtual sandbox at all. It is sieve full of holes!

A simple search at http://web.nvd.nist....?execution=e2s2 for Java
>Search Results (Refine Search)
>There are 142 matching records. Displaying matches 1 through 20.
>
>CVE-2008-5360
>TA08-340A Summary: Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; SDK and JRE 1.4.218 and earlier; and SDK and JRE 1.3.123 and earlier creates temporary files with predictable file names, which allows attackers to write malicious JAR files via unknown vectors.
>Published: 12/05/2008
>CVSS Severity: 6.4 (MEDIUM)
>
>CVE-2008-5359
>TA08-340A Summary: Buffer overflow in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; SDK and JRE 1.4.218 and earlier; and SDK and JRE 1.3.123 and earlier might allow remote attackers to execute arbitrary code, related to a ConvolveOp operation in the Java AWT library.
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5358
>TA08-340A Summary: Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier might allow remote attackers to execute arbitrary code via a crafted GIF file that triggers memory corruption during display of the splash screen, possibly related to splashscreen.dll.
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5357
>TA08-340A Summary: Integer overflow in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; SDK and JRE 1.4.218 and earlier; and SDK and JRE 1.3.123 and earlier might allow remote attackers to execute arbitrary code via a crafted TrueType font file, which triggers a heap-based buffer overflow.
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5356
>TA08-340A Summary: Heap-based buffer overflow in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier might allow remote attackers to execute arbitrary code via a crafted TrueType font file.
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5355
>TA08-340A Summary: The "Java Update" feature for Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier does not verify the signature of the JRE that is downloaded, which allows remote attackers to execute arbitrary code via DNS man-in-the-middle attacks.
>
>Published: 12/05/2008
>CVSS Severity: 10.0 (HIGH)
>
>CVE-2008-5354
>TA08-340A Summary: Stack-based buffer overflow in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows locally-launched and possibly remote untrusted Java applications to execute arbitrary code via a JAR file with a long Main-Class manifest entry.
>
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5353
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows untrusted applets and applications to gain privileges via unknown vectors related to "deserializing calendar objects."
>
>Published: 12/05/2008
>CVSS Severity: 10.0 (HIGH)
>
>CVE-2008-5352
>TA08-340A Summary: Integer overflow in the JAR unpacking utility (unpack200) in the unpack library (unpack.dll) in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier, and JDK and JRE 5.0 Update 16 and earlier, allows untrusted applications and applets to gain privileges via a Pack200 compressed JAR file that triggers a heap-based buffer overflow.
>Published: 12/05/2008
>CVSS Severity: 9.3 (HIGH)
>
>CVE-2008-5351
>TA08-340A Summary: Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier accepts UTF-8 encodings that are not the "shortest" form, which makes it easier for attackers to bypass protection mechanisms for other applications that rely on shortest-form UTF-8 encodings.
>Published: 12/05/2008
>CVSS Severity: 7.5 (HIGH)
>
>CVE-2008-5350
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows untrusted applications and applets to list the contents of the operating user's directory via unknown vectors.
>Published: 12/05/2008
>CVSS Severity: 5.0 (MEDIUM)
>
>CVE-2008-5349
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier, and JDK and JRE 5.0 Update 16 and earlier, allows remote attackers to cause a denial of service (CPU consumption) via a crafted RSA public key.
>Published: 12/05/2008
>CVSS Severity: 7.1 (HIGH)
>
>CVE-2008-5348
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier, when using Kerberos authentication, allows remote attackers to cause a denial of service (OS resource consumption) via unknown vectors.
>Published: 12/05/2008
>CVSS Severity: 7.1 (HIGH)
>
>CVE-2008-5347
>TA08-340A Summary: Multiple unspecified vulnerabilities in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier allow untrusted applets and applications to gain privileges via vectors related to access to inner classes in the (1) JAX-WS and (2) JAXB packages.
>Published: 12/05/2008
>CVSS Severity: 7.5 (HIGH)
>
>CVE-2008-5346
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 5.0 Update 16 and earlier; SDK and JRE 1.4.218 and earlier; and SDK and JRE 1.3.123 or earlier allows untrusted applets and applications to read arbitrary memory via a crafted ZIP file.
>Published: 12/05/2008
>CVSS Severity: 7.1 (HIGH)
>
>CVE-2008-5345
>TA08-340A Summary: Unspecified vulnerability in Java Runtime Environment (JRE) with Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; SDK and JRE 1.4.218 and earlier; and SDK and JRE 1.3.123 and earlier allows code that is loaded from a local filesystem to read arbitrary files and make unauthorized connections to localhost via unknown vectors.
>Published: 12/05/2008
>CVSS Severity: 7.5 (HIGH)
>
>CVE-2008-5344
>TA08-340A Summary: Unspecified vulnerability in Java Web Start (JWS) and Java Plug-in with Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows untrusted applets to read arbitrary files and make unauthorized network connections via unknown vectors related to applet classloading, aka 6716217.
>Published: 12/05/2008
>CVSS Severity: 7.5 (HIGH)
>
>CVE-2008-5343
>TA08-340A Summary: Java Web Start (JWS) and Java Plug-in with Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows remote attackers to make unauthorized network connections and hijack HTTP sessions via a crafted file that validates as both a GIF and a Java JAR file, aka "GIFAR" and CR 6707535.
>Published: 12/05/2008
>CVSS Severity: 9.0 (HIGH)
>
>CVE-2008-5342
>TA08-340A Summary: Unspecified vulnerability in the BasicService for Java Web Start (JWS) and Java Plug-in with Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows untrusted downloaded applications to cause local files to be displayed in the browser of the user of the untrusted application via unknown vectors, aka 6767668.
>Published: 12/05/2008
>CVSS Severity: 5.0 (MEDIUM)
>
>CVE-2008-5341
>TA08-340A Summary: Unspecified vulnerability in Java Web Start (JWS) and Java Plug-in with Sun JDK and JRE 6 Update 10 and earlier, and JDK and JRE 5.0 Update 16 and earlier, allows untrusted JWS applications to obtain the pathname of the JWS cache and the application username via unknown vectors, aka CR 6727071.
>Published: 12/05/2008
>CVSS Severity: 5.0 (MEDIUM)
>

I wouldn't trust any Javascript or Java applets over ActiveX, ever... And all browsers use Javascript, and ActiveX alas... (except non-Windows platforms). Yet on non-Windows platforms, the omnipresent Java and Javascript with all its vulnerabilities are still present however...

[cmaurand]

Chrome? really? The least secure of them all. It sends a whole pile of information to Google so they can target advertising at you. Chrome is spyware.

[cmaurand]

"I wouldn't trust any
Javascript or Java applets over ActiveX, ever... And all browsers use
Javascript, and ActiveX alas... (except non-Windows platforms). Yet on
non-Windows platforms, the omnipresent Java and Javascript with all its
vulnerabilities are still present however..."

The difference between Java and ActiveX is monumental. Depending upon how a java applet is started determines whether it runs in a sandbox or not. If its an applet not locally installed, i.e. downloaded and run each time you click on it, it runs in a sandbox. If its something like the Eclipse platform, it runs locally and has access to the system at the same level as the user or elevated, depending upon how its been set up.

ActiveX on a web page has access to your system objects, registry, etc. That's a sieve. Java applets not installed locally do not have that kind of access (or at least by definition don't.) The idea is that the runtime is supposed to insulate the system from the applet. I suppose by definition that constitutes at least 2 security zones.

again, I don't trust anything from the web.

[rohnski]

Good article, I'll be pointing it out to friends, but I wonder about your choice of versions to report on.
IE8, well that's a beta subject to change.
FireFox 3.12, where does that version number come from? Current version is 3.0.6. From what I read, the next version, still in beta (also) is 3.1. Even 3.1.2 is not a plausible version number.
Chrome version numbers have four decimals (like an IP) so saying V1 is a little light.
But what the hay, 2 out of 5 is not bad, right?

[Jesant13]

Nice review, it was helpful. =)