[ACE] Arbitrary Code Execution - Execute Java code in chat or console

I’ll rebuild this page someday.

Get it here if you know what you’re doing: Releases · DDoS/ACE · GitHub


If you could get this plugin to run plugins via src fetched from Github, oh boy.

For some reason that reminds me of this: http://www.youtube.com/watch?v=Uep1H_NvZS0#t=1910

Nice idea, but oh the security holes. Here be dragons for sure. I hope no one puts this on a production server no offense, just the holes.


To be fair, once someone gets arbitrary permission access they’re going to mess a LOT of things up, with or without this plugin… just normally they wouldn’t be able to screw with your file system. At that point, you’d be restoring the entire Minecraft user files from backup regardless…

1 Like

Theres a lot more that you could do than just the file-system. The file-system is just lowest hanging fruit. Which while it’s what most people go for, doesn’t mean everyone will go for it.

Any specific reason you chose not to use a pre-existing project like BeanShell and instead wrote your own interpreter?

I don’t really understand why you should allow remote code execution :worried:.

/acee Runtime.getRuntime().exec("bash rm * -r && killall java");

You know what would make sense? Write code in books, then execute them by running /ace run or something.
It would be rather tedious to use commands for this sort of thing.

Oh, and:

/acee Runtime.getRuntime().exec("rm -rf /")

Would only work if the server is running as root ;). What nobody does offcourse ? But actually if you don’t have the intention to trash a server, executing shell commands could be really useful.

1 Like

In which case you create shell scripts, and start them through there. Arbitrary code execution that anyone can execute at anytime is not the brightest idea. Some administrative actions could be nice but, those should managed securely. The simple fact is this screams bad things everywhere.

Also yes. I have seen tons of people run it as root ;~;. Like tons. Because they some how think that’s secure. Some people ;~;

1 Like

I am very aware of security issues with this plugin, but it is not intended as a production plugin. This is for testing and development. Anyone running this on a live server is an idiot.

The goal of this plugin is to let you call methods and print data to the chat for debugging. This is faster than having to write plugins to test new features.

This is just a quick front-end I threw together in an hour or two. Anyone could use the actual eval library to add such functionality to a plugin.

That wouldn’t be any fun. I’m also targeting a specific subset of Java and preferred making my own rather than trying to adapt BeanShell.


You may want to make that the first or second line on your description, because in my head I see owners/ten-year-old-kids who aren’t tech savvy putting this on, then a tide of fire as servers are destroyed by “sudo rm -rf /” and the wall of angry rants and bug reports that follow it.

I added another warning at the top of the post.

New release!

Improved error handling a lot. You should now get more comprehensive error messages pointing exactly what when wrong.

I also fixed many issues with the type checker.

Eh, anybody who can program in java (why else would one want this?) should at least know that one can do bad things… Although you’re right about the warning.


I would personally suggest not publishing compiled binaries for this, since Joe Schmo could come along and open a huge vulnerability on his server, whereas if only the source is available it’s likely that everyone able to compile it knows sufficiently what they’re doing.

If a user disregards all warning and runs this, it isn’t really anybody’s fault but the user.

It’s better to not provide them with the opportunity to screw their server up in the first place, aye? I’m not saying the binaries should definitely be taken down. that’s just my personal opinion.

Even if he just publishes the source and Joe Schmo disregards all warnings, compiles, and runs it, still just his fault.