full-disclosure - 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <242a0a8f0603271418k84a9661uc964be661cd7360@mail.gmail.com>
Date: Mon Mar 27 23:18:25 2006
From: eaton.lists at gmail.com (Brian Eaton)
Subject: 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, User vs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code

On 3/27/06, Pavel Kankovsky <peak@...o.troja.mff.cuni.cz> wrote:
> On Sat, 25 Mar 2006, Dinis Cruz wrote:
> Are .Net, Mono, or Java themselves 100% managed and verifiable code?
> Can you create a secure environment when it is, using your own words,
> "impossible to create bug/vulnerability free code"? I know there have been
> vulns in the JRE making it possible to break out of the sandbox and
> similar vulns in the other environments would not suprise me.

It's worth distinguishing between the problems posed by mobile code
and the problems posed by ancient programming languages that don't
have bounds checking built-in.

If I run a pure-java browser, for example, no web site's HTML code is
going to cause a buffer overflow in the parser.  You'll see a nasty
"array index out of bounds" exception, but the stack doesn't get
smashed and there is no execution of arbitrary code.  That's managed
code.

OTOH, an applet downloaded from that web site might break the JRE,
causing a buffer overflow.  If I were running this hypothetical
pure-java browser, I'd still be relucant to enable applets because I
don't trust the applets and I don't trust the JRE byte-code verifier
to validate the applet.  That's mobile code.

Regards,
Brian