Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs I

Subject: Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Date: Mon, 27 Mar 2006 17:18:15 -0500
On 3/27/06, Pavel Kankovsky <peak@argo.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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

<Prev in Thread] Current Thread [Next in Thread>