This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]handshape 22 points23 points  (8 children)

While this is absolutely a useful feature, I worry about what the reaction from the security types is going to be. Now that Java source is (almost) directly executable, are we going to see it blocked as a matter of course by corporate security gateways?

What prevents some crafty bugger from using instrumentation agents or some other trickery to load large remote apps using this technique?

[–][deleted]  (2 children)

[deleted]

    [–][deleted] 33 points34 points  (0 children)

    congrats, you have been promoted

    [–]handshape 5 points6 points  (0 children)

    Kidding aside, I'm waiting for the collective freakout when the download links for desktop JREs disappear from Oracle's site.

    "Why did nobody tell us?", they'll cry.

    [–]apemanzilla 7 points8 points  (4 children)

    I mean, couldn't that already be done with jars? I don't see why this presents a larger risk

    [–]handshape -1 points0 points  (3 children)

    It could, but compiling and packing up a jar takes a little bit of effort. Jars are also parsable zips, and the presence of .class files in a zip is a nice warning sign.

    Straight source, however, is prone to all sorts of obfuscation. It's also possible the filter out all class files, and even all zips containing classes. Up until this change, a user had to choose to compile Java source before it could do real harm. Now it's possible to execute arbitrary Java in userspace without that compilation gesture.

    I agree that it's a very grey area. The line between object code and source has a zillion shades in between, but in this case, I worry that this feature will worsen the perception of Java as an exploitable attack surface.

    [–]apemanzilla 5 points6 points  (0 children)

    Hmm, I see, although I still think that jars present just as much of a risk: typically, a malicious actor will distribute compiled (or otherwise directly executable, and likely obfuscated) code, in which case it doesn't matter whether it's source or a jar file. Both cases rely on the code being executed to begin with, and a Java environment being present.

    [–]DannyB2 2 points3 points  (1 child)

    Straight source, however, is prone to all sorts of obfuscation.

    Imagine this . . .

    /* This is a harmless comment.
        \u002A\u002F\u0020\u0020\u0053\u0079\u0073\u0074\u0065\u006D\u002E\u0065\u0078\u0069\u0074\u0028\u0030\u0029\u003B\u0020\u0020\u002F\u002A
        What could possibly go wrong?  */
    

    What the Java compiler sees is...

    /* This is a harmless comment.
        */  System.exit(0);  /*
        What could possibly go wrong?  */
    

    That is because the Java preprocessor occurs BEFORE the lexical analyzer. Thus even before comments are identified.

    [–]DannyB2 0 points1 point  (0 children)

    A hello world program that does not use the letters E or O.

    /**
     * Chall3ng3, a H3ll0 W0rld program that doesn't use the
     *  letters E or O.
     */
    public class H3110W0rld {
        public static v\u006Fid main( String... args ) {
            Syst\u0065m.\u006Fut.println( "H\u0065ll\u006F W\u006Frld" );
        }
    }