RCE Through JDWP Debug Port

[ghost]

Describe the bug
Remote code execution is achievable through the JDWP debug port 18001 which is opened to all interfaces when launching in debug mode.

To Reproduce
Steps to reproduce the behavior:

1. Open the program with the debug launcher dependent on your OS.

Expected behavior
No remote code execution

Environment (please complete the following information):

• Any Windows/Linux build running with debug mode.

Additional context
Credits: https://twitter.com/hackerfantastic/status/1103087869063704576

[ghost]

Updated to reflect new information.

[RobRoseKnows]

I commented on the Tweet with this too: but I don't really think this classifies as a bug. Debug mode isn't the default and it's expected behavior that debug mode would, you know, open debug ports.

[ghost]

The issue isn't that it's opening the port, it's that it opens the port on all interfaces, not just locally.

[ctubbsii]

I wonder if it would be useful to make the debug listening interface/port configurable (if not already) and to default to localhost.

[silascutler]

It may be possible to set to a specific interface, by changing:

VMARG_LIST+=" -Xrunjdwp:transport=dt_socket,server=y,suspend=${SUSPEND},address=*:${DEBUG_PORT}"

to

DEBUG_INTERFACE=<SOMETHING>
...

VMARG_LIST+=" -Xrunjdwp:transport=dt_socket,server=y,suspend=${SUSPEND},address=${DEBUG_INTERFACE}:${DEBUG_PORT}"

[nneonneo]

It is often useful to debug a misbehaving program from a different computer, or (for example) debug a misbehaving program inside a VM from outside. So, I'm not sure this really qualifies as a bug.

[ghost]

Kernel debugging isn't really the same thing, mainly because if you mess up while doing so the VM bluescreens, which is why debugging remotely is helpful. Here it doesn't seem to have nearly as much usefulness. The fact that this is the default behavior is what's concerning.

[qwerty01]

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

[bartekus]

As @DefCon42 mention already

The fact that this is the default behavior is what's concerning.

Indeed, as I'm sure NSA is already well aware, hacker-folk are highly distrustful and trust is a fragile thing. Perhaps outlining all the basic specifics regarding the software architecture and its intended purpose could help calming them... Just saying.

[nneonneo]

I wasn’t referring to kernel debugging - debugging an app running in a foreign OS counts too (think debugging the app running in a Linux VM using Windows tools).

I can understand the concern - maybe it needs improved documentation?

[WriteCodeEveryday]

As @DefCon42 mention already

The fact that this is the default behavior is what's concerning.

Indeed, as I'm sure NSA is already well aware, hacker-folk are highly distrustful and trust is a fragile thing. Perhaps outlining all the basic specifics regarding the software architecture and its intended purpose could help calming them... Just saying.

There's probably a command and control component that uses this inside of a VM for analysis.

[ghost]

Remove set if needed in ghidraDebug.bat/sh if non-remote.

:: set debug port
set DEBUG_PORT=18001

Checkout GhidraServer regarding network I/O.

main(String[] args)

[ghost]

I wasn’t referring to kernel debugging - debugging an app running in a foreign OS counts too (think debugging the app running in a Linux VM using Windows tools).

I can understand the concern - maybe it needs improved documentation?

Improved documentation is definitely a must -- I wouldn't put something that allows this type of execution under the name "debug."

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

Issue A is that this isn't explicitly labeled as a debug server -- just under the obscure name "debug mode."
Issue B is that not every debug server you've used allows arbitrary code execution on the target.

https://twitter.com/hackerfantastic/status/1103109539589632000

[philippTheCat]

It is JDWP, it is the protocol that IDE's use to connect to the program. This needs to include arbitrary code execution if you want to do any substantial work with it.

[Amphyby]

ROFL it's just a trojan from NSA team. what did you expect? :D
funny 'hackers' all around

[joepie91]

How is this an issue? Every debug server I've used listens on 0.0.0.0 by default...and RCE is a really heavy term to use even if it wasn't normal behavior

Mind sharing your IP, in that case?

Reasonably-designed tools - debug servers or otherwise - never listen on 0.0.0.0 unless explicitly told to do so.

[cym13]

Binding on 127.0.0.1 would help but it would still be vulnerable to DNS rebinding attacks IIUC. Can this be turned off by default or use authentication?

EDIT: just noticed it's off unless launched in debug mode, seems fair to me.

[paragonie-scott]

My thoughts: Listening on 0.0.0.0 should still be permitted, but should not be the default value.

Secure-by-default is the only meaningful security configuration in the real world, after all. NSA might have the discipline to not do something boneheaded with an insecure default, but not everyone is NSA.

[briangordon]

Give me a break. This is a legitimate issue that should be fixed, but it's ridiculous to call this a deliberate backdoor. The whole point of releasing a massive project like this as open source is to win brownie points with the community, and that's rather undermined if there's a dead obvious backdoor staring everyone in the face. Who runs desktop applications on machines with network interfaces completely open to the public internet anyway? You almost always have a NAT in front of desktop machines, and firewall rules on servers.

[c0d3x27]

@qwerty01 °NSA° those words dont tell you anything? thats the issue every one have

[bcosinc]

Wow! I'm glad you found this in under a day. You're quite the l33t master hacker @DefCon42. To think, the NSA spent however long to develop this and YOU exposed their super secret non-default debug mode RCE "hack". To think, all of us loser n00bs out here ALWAYS run our RE activities on live boxes attached directly to the Internet with no firewalls anywhere in sight. YOU saved us all. I can wait to see what else you contribute. Can you find the other 900000 "RCE backdoors" in this project?

Give me a break.

[ctubbsii]

Okay folks, let's please keep the conversation civil. The issue that was reported is essentially that the default bind address for when debugging is turned on could be improved by binding by default to 127.0.0.1 instead of 0.0.0.0.

It's a reasonable suggestion for improvement, and the suggestion is appreciated. Now, let's give the developers a chance to address it. If they determine that there's a reasonable use case to leave the default at 0.0.0.0 (for convenience debugging or whatever), then perhaps they can still address it by improving the documentation to better warn users of the implication of enabling debugging.

There is a reasonable path forward here. There's no need to be uncivil to each other.

[ghost]

Wow! I'm glad you found this in under a day. You're quite the l33t master hacker @DefCon42. To think, the NSA spent however long to develop this and YOU exposed their super secret non-default debug mode RCE "hack". To think, all of us loser n00bs out here ALWAYS run our RE activities on live boxes attached directly to the Internet with no firewalls anywhere in sight. YOU saved us all. I can wait to see what else you contribute. Can you find the other 900000 "RCE backdoors" in this project?

Give me a break.

1. I didn't find it, as clearly stated in the issue.
2. This is a (soon to be) open source project which anyone can run. The problem isn't the experienced reverse engineers who run this under however many layers of security, it's the guys who download this on, say, a campus-wide school network. If it's going to expose a port on every interface then it should be well-documented that it does so.
3. Expanding on 2, I never called this a backdoor. It's simply an overlooked consequence of having undocumented default behavior.

If they determine that there's a reasonable use case to leave the default at 0.0.0.0 (for convenience debugging or whatever), then perhaps they can still address it by improving the documentation to better warn users of the implication of enabling debugging.

There is a reasonable path forward here. There's no need to be uncivil to each other.

Even if the default is to have it open (a.la ADB), there are many ways to improve it. Some sort of public/private key authentication or otherwise would be plenty.

[qwerty01]

Issue A is that this isn't explicitly labeled as a debug server -- just under the obscure name "debug mode."
Issue B is that not every debug server you've used allows arbitrary code execution on the target.

A - It's not default behavior, so I don't see how it would be mistaken for something other than that, but adding better documentation for that would probably be a good idea.
B - What? That's literally the definition of a debug server--executing arbitrary code on the target.

[Albocoder]

B - What? That's literally the definition of a debug server--executing arbitrary code on the target.

That's true but how many debuggers do you know that listen to the ENTIRE WORLD instead of the localhost? I could think of ADB on top of my head that has the remote functionality but it uses PKI based solution to authenticate the user first. This however allows the whole world to connect with no authentication.

[WriteCodeEveryday]

For everyone who is complaining, the PDF https://www.rsaconference.com/writable/presentations/file_upload/png-t09-come-get-your-free-nsa-reverse-engineering-tool_.pdf, slide 23 speaks about running analysis without a GUI.

[qwerty01]

That's true but how many debuggers do you know that listen to the ENTIRE WORLD instead of the localhost? I could think of ADB on top of my head that has the remote functionality but it uses PKI based solution to authenticate the user first. This however allows the whole world to connect with no authentication.

So does gdbserver and all the ida servers, it's industry standard to have a debug server listen on * since it's meant for remote debugging, not local debugging.

However, it seems I misunderstood the context--apparently debug mode is for debugging Ghidra, not an arbitrary binary. This definitely needs to be fixed.

[ryanmkurtz]

Thanks for all of the feedback on this issue! 127.0.0.1 will be used by default in our next release. It will also be a little easier to set the debug script variable to a different ip:port combo in the launcher scripts in the case where remote debugging is required.

[ctubbsii]

@ryanmkurtz Nice use of the milestone feature in GitHub! 👍