[SC-L] 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
> of creating a > full-featured > browser, from scratch, with usability as good as IE > and Firefox > strikes me as a fairly tricky project. I agree. > What about > using the > facilities already provided by the OS to enforce the > sandbox? But then will it be possible to prevent buffer overflows, still running on unmanaged code? Very nice points by Dinis, esp. the one about the "advantages" of using our boxes with less privileges (for internet browsing). -pilon --- Brian Eaton <[EMAIL PROTECTED]> wrote: > On 3/25/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: > > 4) Finally, isn't the solution for the creation of > secure and > > trustworthy Internet Browsing environments the > development of browsers > > written in 100% managed and verifiable code, which > execute on a secure > > and very restricted Partially Trusted > Environments? (under .Net, Mono or > > Java). This way, the risk of buffer overflows will > be very limited, and > > when logic or authorization vulnerabilities are > discovered in this > > 'Partially Trusted IE' the 'Secure Partially > Trusted environment' will > > limit what the malicious code (i.e. the exploit) > can do. > > I am less than enthusiastic about most of the > desktop java > applications I use. They are, for the most part, > sluggish, memory > gobbling beasts, prone to disintegration if I look > at them cross-eyed > or click the mouse too frequently. > > Usability problems with java applications are not > necessarily due to > managed code, of course, but the idea of creating a > full-featured > browser, from scratch, with usability as good as IE > and Firefox > strikes me as a fairly tricky project. What about > using the > facilities already provided by the OS to enforce the > sandbox? Rather > than scrapping the existing codebases, start running > them with > restricted rights. Use mandatory access control > systems to make sure > the browser doesn't overstep its bounds. > > Regards, > Brian > > - > This List Sponsored by: SpiDynamics > > ALERT: "How A Hacker Launches A Web Application > Attack!" > Step-by-Step - SPI Dynamics White Paper > Learn how to defend against Web Application Attacks > with real-world > examples of recent hacking methods such as: SQL > Injection, Cross Site > Scripting and Parameter Manipulation > > https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=70130003gRl > -- > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] 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
no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael On 3/29/06, Pavel Kankovsky <[EMAIL PROTECTED]> wrote: > On Mon, 27 Mar 2006, Brian Eaton wrote: > > > 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. > > Even a "pure-java browser" would rest on the top of a huge pile of native > code (OS, JRE, native libraries). A seemingly innocent piece of data > passed to that native code might trigger a bug (perhaps even a buffer > overflow) in it... > > Unlikely (read: less likely than a direct attack vector) but still > possible. > > --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] > "Resistance is futile. Open your source code and prepare for assimilation." > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] 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
no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael On 3/29/06, Pavel Kankovsky <[EMAIL PROTECTED]> wrote: > On Mon, 27 Mar 2006, Brian Eaton wrote: > > > 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. > > Even a "pure-java browser" would rest on the top of a huge pile of native > code (OS, JRE, native libraries). A seemingly innocent piece of data > passed to that native code might trigger a bug (perhaps even a buffer > overflow) in it... > > Unlikely (read: less likely than a direct attack vector) but still > possible. > > --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] > "Resistance is futile. Open your source code and prepare for assimilation." > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] 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
This is not quite true. Java does not prevent integer overflows (it will not throw an exception). So you still have to be careful about array indexes. Andrew On 29/03/2006, at 12:49 PM, [EMAIL PROTECTED] wrote: no, a browser written in java would not have buffer overflow/stack issues. the jvm is specifically designed to prevent it ... -- Michael smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] 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
No you dont.
Arrays are all bounds checked; ..., that is, the following code will
throw an exception:
class Foo {
static {
int[] m = new int[2];
System.out.println(m[34]);
}
}
What do you mean by "overflow"? Do you mean this?
class Foo {
static {
int m = Integer.MAX_VALUE;
int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
System.out.println(m);
System.out.println(k);
System.exit(0);
}
}
if so, I don't see how that is an issue.
-- Michael
On 3/29/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
> This is not quite true.
>
> Java does not prevent integer overflows (it will not throw an
> exception). So you still have to be careful about array indexes.
>
> Andrew
>
> On 29/03/2006, at 12:49 PM, [EMAIL PROTECTED] wrote:
>
> > no, a browser written in java would not have buffer overflow/stack
> > issues. the jvm is specifically designed to prevent it ...
> >
> > -- Michael
>
>
>
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] 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
> no, a browser written in java would not have buffer overflow/stack > issues. the jvm is specifically designed to prevent it ... And of course, we all know all JVM implementations are perfect. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
