[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8mi3q7Raqj99d5d59-r72fadGx5NOSLegNuDmOp9Ux9uA@mail.gmail.com>
Date: Sat, 20 Jul 2013 13:36:47 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Security Explorations <contact@...urity-explorations.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: [SE-2012-01] New Reflection API affected by a
known 10+ years old attack
On Thu, Jul 18, 2013 at 12:50 AM, Security Explorations
<contact@...urity-explorations.com> wrote:
>
> Hello All,
>
> We discovered yet another indication that new Reflection API introduced
> into Java SE 7 was not a subject to a thorough security review (if any).
I'm kind or surpised some of these bugs exist for so long. Allowing
them to fester and rot can't be good (I have not been able to come up
with a use case where it is desired or preferred).
Does anyone know anything about Oracle's engineering process? What is
Oracle doing to ensure issues are tracked and remediated in reasonable
time? What does the process include for code scanning to catch low
hanging fruit? Are they using Find Bugs or Coverity (I checked
scan.coverity.com, and I did not see Oracle Java or OpenJDK listed, so
I wonder if they are doing it internally). What is the QA process
doing to ensure items with negative impact are not allowed to pass?
Jeff
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists