It doesn't seem true here, I think only if you use the support script. I guess it was intended to allow a support engineer to debug problems remotely, it seems to be documented. 
-
-
Replying to @taviso @MalwareJake
It's only if you use "debug" as a launch mode instead of "fg" or "bg" (default). I wouldn't expect it to open a remotely accessible debug port, I would expect it to have listened on localhost. YMMV but I've exploited it already for RCE.
3 replies 2 retweets 6 likes -
Is using an intentional debug interface really an RCE?
1 reply 0 retweets 12 likes -
Yes, it should not listen to every interface. See https://static.hacker.house/releasez/expl0itz/jdwp-exploit.txt … for more details.
1 reply 0 retweets 1 like -
What if you want to debug across LAN or from outside a VM? Maybe the interface should default to localhost, but definitely not an RCE.
1 reply 0 retweets 12 likes -
It's an RCE, I've posted screen shots demonstrating it being used to launch new processes. It should be listening on localhost only by default.
2 replies 1 retweet 3 likes -
I think there's no debate on that, just that if you enable debugging you would reasonably expect debugging to be enabled. IDA has a debug server too, there's no password by default, you have to specify it on the command line if you want one.
4 replies 2 retweets 23 likes -
Replying to @taviso @hackerfantastic and
Debug interfaces need authentication if they take place over an interface like network socket rather than something access controlled like a unix socket. This isn't 1990.
0 replies 2 retweets 8 likes -
Replying to @MalwareTechBlog @taviso and
Not just WAN; even localhost is exposed in all sorts of ways. Browser-based CSRF, sandboxed maybe-malicious processes, possibly-compromised low-privilege local user accounts, etc. Network-based access control is always wrong.
2 replies 1 retweet 2 likes
I think all debuggers in common use have an option to enable network-based access control that isn't enabled by default. It sounds like you have a lot of bugs to file if you really believe that, e.g. https://sourceware.org/gdb/onlinedocs/gdb/Server.html …
-
-
Replying to @taviso @MalwareTechBlog and
Yes I'm aware that's a problem with gdbserver if run listening on a socket, but you can instead hook it up to a pty or something else. Shipping a configuration where it listens on a socket would be a security bug.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @taviso and
Ideal gdbserver setup (and I use this in practice) is over a pty over ssh.
1 reply 0 retweets 0 likes - 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.