Message-ID: <51EAC17C.3080603@security-explorations.com>
Date: Sat, 20 Jul 2013 18:57:32 +0200
From: Security Explorations <contact@...urity-explorations.com>
To: Michael Schierl <schierlm@....de>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [SE-2012-01] New Reflection API affected by a
 known 10+ years old attack


Hello,

> I don't
> think it is fair how you try to display yourself as if you were the only
> person who was able to find these kind of flaws - you are certainly the
> most bragging and egoistic one of those (and online security sites
> always happily pick up anything you wrote).

Most bragging and egoistic ? Is is because:
- we let people know that a given security technology is insecure, so that
   those that want or need to be in the know have a chance to be at least
   aware of the threat ?
- we don't share our Java findings with governments, other vendors, OpenJDK
   or friends on Twitter. Not even for money,
- we inform a vendor and a public on the same day about our findings, thus
   effectively put the vendor under some slight pressure to act promptly ?
- we criticize a vendor that deserves the criticism ?

Here at Security Explorations, we are not envy if someone does a good job,
publishes a quality research, comes across some nice / interesting bug or
exploit technique (not necessarily related to Java).

We are not envy if someone wins Pwn2Own in a Java category. Same if a Java
bug hunter decides to cash its own findings through a vulnerability buying
/ reward program, etc.

We don't judge other Java / security researchers actions. We don't tell them
what to do.

We do our Java security research completely for free. Thus, we think that we
have a full right to publish it in a way / form of our choice.

Visibility is a "side effect" of our actions, but not our goal. The lack of
"In the news / media" section on our website should be self-explanatory.

Some (such as you) may not like it. That's completely OK for us. Your voice
is heard, but it is very unlikely that it is gonna change us.

Java security research creates equal opportunities for everyone. Instead of
bragging about "unfair" visibility of one specific party, maybe you should
jump in to the game too. Competition in the field is always welcome as this
forces us (and Oracle in particular) to work harder.

> Your argument is a bit
> about like that burglary is know for centuries, but the current
> alarm systems still do not "properly" detect all kinds of that type of
> crime (because there are just too many ways to get into a stranger's
> house illegitimately).

The referenced LSD paper contains description of the attack. This attack
originally goes back to early days of Java (late 90s). Your reasoning is
not necessarily correct. It is thus advised to wait till more information
about Issue 69 is published for further discussion of the above.

> So if you
> really want to help Java Security and have a bit of time to spare, get
> one of the Java 8 Early Access Builds and have a look at the new stuff

Please, allow that we choose the targets of our security research efforts
on our own. This is our time and money (and our TODO.txt list).

> This is certainly not limited to Oracle. If you have a look at bug
> bounties paid by Google, you will notice that a large percentage of them
> was paid to products that have been acquired recently or after some
> large new third party code has been added to a product; it is virtually
> impossible to review third party code thoroughly enough so that no
> vulnerabilities remain.

Sun Microsystems has been aware of Reflection API flaws since 2005. Oracle
took over in 2010 and its stricter Software Security Assurance procedures
were apparently enforced for Java (according to the blog post referenced
in our previous post).

Reflection API was a known security risk. It's not that difficult to hunt
down simple instances of these flaws (we do all of our work manually and
Oracle apparently uses sophisticated analysis tools).

We are perfectly aware that it is rather impossible to review code in a
way so that no vulnerabilities remain. But, leaving a huge pile of simple
instances of Reflection API weaknesses for sure does not speak well of
Oracle's policies and procedures.

Thank you.

Best Regards
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

_______________________________________________
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