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: <5e01c29a0603281950m3b6f1617uc788c454af48b0af@mail.gmail.com>
Date: Wed Mar 29 04:50:27 2006
From: michaelslists at gmail.com (michaelslists@...il.com)
Subject: Re: Java integer overflows (was: a really long
	topic)

right,

but we're talking about unmanaged vs managed, and the earlier poster
(i think it might've been "pavel" [sorry if it wasn't]), said that
100% java is still vulnerable to buffer overflows. the fact is that it
isn't.

-- Michael

On 3/29/06, Andrew van der Stock <vanderaj@...ebo.net> wrote:
> I'm not talking arbitrary code execution, I'm talking about odd code
> paths, bizarre outcomes, and DoS.
>
> For example (found via 19 Sins, Viega, Howard and LeBlanc):
> http://seclists.org/lists/bugtraq/2004/Nov/0097.html
>
> I know Michael reads webappsec, he may have more examples.
>
> In my own code testing, I look for silly behaviors if a user can
> insert a large or negative number. You'd be surprised how often it
> occurs. There is no excuse not to include basic range checks when
> performing data validation.
>
> thanks,
> Andrew
>
> On 29/03/2006, at 2:30 PM, michaelslists@...il.com wrote:
>
> > 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 <vanderaj@...ebo.net> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ