The document discusses Java's vulnerabilities and security mechanisms, emphasizing the need for regular updates and removal of outdated versions to ensure safety. It highlights the prevalence of Java 6 as the most vulnerable version, which is still widely used despite the availability of more secure alternatives like Java 7. Additionally, it outlines best practices for managing Java installations in order to mitigate security risks associated with exploits targeting older versions.

1. ©2010 Improving Enterprises, Inc.
Lets talk about
Java Safety
Jane Prusakova
@Improving Enterprises

2. ©2010 Improving Enterprises, Inc.
TIOBE
Programming
Community Index
Java 16% - 1st
C# 6.1% - 6th

3. ©2010 Improving Enterprises, Inc.
Most exploited holes
Many vulnerabilities and exploits found recently

4. ©2010 Improving Enterprises, Inc.

5. ©2010 Improving Enterprises, Inc.
Write once, run anywhere
Ubiquitous
Over 20 years old
Security model first implemented in 1.1.5 -
stack inspection with scopes [broken]
Exploits combine more than one
vulnerability

6. ©2010 Improving Enterprises, Inc.
Java security mechanism
Java stack inspection mechanism makes it impossible to abuse
target system’s security by the means of arbitrary injection of a
stack frame belonging to untrusted code inside a privileged code
block (scope).
Security Manager’s check methods verify permissions of all the
classes from a current scope (call stack). Stack frames are
inspected until either the end of a call stack or a special
(privileged) frame is reached.
The permission check will succeed only if all classes from a
current code scope have a given permission granted. In the case
of encountering an unprivileged stack frame, security exception
is thrown, and execution is aborted.

7. ©2010 Improving Enterprises, Inc.
Java security mechanism
Concept
Powerful & clever
Single issue rarely
leads to full-blown
exploit
Mechanism
Complex and hard to
implement
Poor design and
implementation choices
abound

8. ©2010 Improving Enterprises, Inc.
Vulnerable APIs
Reflection API
access restricted classes, fields and methods
create restricted objects
Invoke restricted methods
XML Beans Decoder
Specially crafted XML can inject an arbitrary
user-defined class into trusted code

9. ©2010 Improving Enterprises, Inc.
Vulnerable implementation
Bytecode Verifier does not properly verify
the bytecode instruction stream for the
invokespecial
RMI implementation does not verify object
type before unmarshalling remote object.

10. ©2010 Improving Enterprises, Inc.
So what?
One or more vulnerabilities are used to
compromise the Java sandbox
Intruder process can execute arbitrary code
on host machine
Install software, read, change and delete data

11. ©2010 Improving Enterprises, Inc.
Will I get hacked?
Win the lottery
1.1 billion desktops
3 billion mobile phones
Run Java version(s) with known exploits
Subject to popular, untargeted attacks

12. ©2010 Improving Enterprises, Inc.

13. ©2010 Improving Enterprises, Inc.
Java: newer is better
(on the average, most of the time)
Known bugs get patched
Exploits take time to be prepared and
distributed
Most organizations are slow to upgrade
therefore exploiting older, more popular
systems is easier and better value
attack on a brand-new system less likely

14. ©2010 Improving Enterprises, Inc.
Multiple versions of Java
Installed
Exposed through
the browser

15. ©2010 Improving Enterprises, Inc.
Which Java?
Java 6 (1.6) is the
most vulnerable
Java 7 is the most
secure
Java 6 is by far
most prevalent
82% endpoints

16. ©2010 Improving Enterprises, Inc.
Many and old versions
The average organization has more than
50 distinct versions of Java
93% of organizations run a version of Java
5+ years old

17. ©2010 Improving Enterprises, Inc.
Update is not upgrade
Java update does not remove older
versions

18. ©2010 Improving Enterprises, Inc.
Why remove older versions?
Exploits can specify which Java version to
run
So a more vulnerable Java install can be
targeted
Without user knowledge*
Even if newer and safer version is installed

19. ©2010 Improving Enterprises, Inc.
Creating a safer environment
Use Java safely
Regularly upgrade to latest, best patched version
Remove all other installs
Remove all Java
Remove all Java installs
Java embedded in other products is safe
If it is not made available to the browser

20. ©2010 Improving Enterprises, Inc.
Use Java Safely
Determine the safest version
Less popular version may be more
secure
Establish regular upgrade schedule
Ensure removal of earlier versions
Audit regularly for unauthorized installs

21. ©2010 Improving Enterprises, Inc.
Remove Java completely
Use tools to verify and manage uninstalls
Monitor network (layer-7 visibility tools)
Audit for unauthorized installs
Pick replacement technology
Ensure its safety

22. ©2010 Improving Enterprises, Inc.
Safety in numbers
Java 16% - most
popular
1.1bln desktops
Good / Better /
Best
Perfect

23. ©2010 Improving Enterprises, Inc.
Questions?
Jane.Prusakova@ImprovingEnterprises.com
SoftwareAndOtherThings.blogspot.com
@jprusakova
Jane Prusakova
http://www.slideshare.net/jprusakova

24. ©2010 Improving Enterprises, Inc.
Lets talk about
Java Safety
Jane Prusakova
@Improving Enterprises

25. ©2010 Improving Enterprises, Inc.
References
Kaspersky Lab report: Evaluating the
threat level of software vulnerabilities.
February 1, 2013
Java SE security research project
Security Explorations, 2013
Bit9 research report: Java Vulnerabilities:
Write Once, Pwn Anywhere. 2013

26. ©2010 Improving Enterprises, Inc.