January 14, 2018 6:03 PM, "Christopher Head" <open...@chead.ca> wrote:
> I don’t think that just blocking HTTP verbs is good enough. Let’s consider > some more examples. > > Example 1: Alice spends lots of time on IRC. She’s also interested in > embedded systems, so she runs > OpenOCD. Bob has a file to send her, so they start an IRC CTCP session. Bob > configures his IRC > client to claim his IP address is 127.0.0.1 and the CTCP listener is on port > 4444. Alice’s IRC > client sends some crud to her OpenOCD, which might include text that Bob can > partially control. > > Example 2: Alice runs an FTP server. Bob connects to it and uploads a file > containing some OpenOCD > script. He then issues an FTP GET command, in active mode, specifying the > data channel to be at > 127.0.0.1:4444. Alice’s FTP server connects to her OpenOCD’s Telnet port and > dumps Bob’s uploaded > file straight into it. > > Example 3: Alice does a lot of online gaming. Bob sends an invitation to a > new server he found. The > invitation contains a hostname, port number, and invitation key used to > authenticate to the server. > The game shows a popup with invitation details: host example.com, port 4444. > The invitation key > isn’t shown, because it’s supposed to be just some random bytes. Unknown to > Alice, Bob went to > Godaddy yesterday and registered example.com, and its DNS server now resolves > example.com to > 127.0.0.1. Also unknown to Alice, the invitation key isn’t as random as it > ought to be: it’s > actually some OpenOCD commands > Related: Some recursors have "DNS rebinding protection", which should filter this. My OpenWRT router seems to have this enabled, the Google 8.8.8.8 nameservers do not. > Example 4: Alice is using her Web browser. She clicks on a link, an act that > should be harmless. It > points at > ftp://some-openocd-script:some-password@localhost:4444/some/filename. Or a > similar Gopher > URL. Or a Websockets URL. Or any number of other protocols that Web browsers > also understand. > lol, this actually works with gopher in elinks. > Example 5: Alice and Bob live together. To save space or money, they share a > single desktop for > serious computing work. They practice good computing hygiene: their home > directories are mode 0700, > they have good passwords, they always log out when done, and they keep their > machine up to date > with security patches. They sometimes need access to their personal files > while they’re out, so > they set up SSH access from their phones. Alice, sitting at the desktop, runs > OpenOCD. Bob, sitting > at the coffee shop, runs ssh -L4444:localhost:4444 homebox. > > I’m not claiming to have tested all of the above. I’m not claiming that all > of the above are > actually workable attacks. Rather, they’re a few examples I wrote up while > waiting for a bus. If I > can think of these, no doubt a dedicated attacker can think of many more, and > some of them will > work even if not all of them do. In my opinion, blindly trusting localhost is > the fundamental > problem here: none of the above attacks would work if you had to, say, type a > password before > OpenOCD would accept your Telnet (or GDB, or TCL, or …) session. A slightly better option: provide a simple "client" binary, which connects to a UNIX socket/Windows named pipe or whatewer is actually supposed to serve for communication between applications on the same computer. netcat-openbsd even has -U option for connecting to an unix socket. Note: Unix sockets can apparently be forwarded over SSH natively, without fumbling with socat - https://lwn.net/Articles/609321/ As these are annoyingly platform dependent, another alternative is keeping TCP and using a "cookie" file, such as Tor does - https://stem.torproject.org/faq.html#i-m-using-cookie-authentication The client binary could load this file transparently, from some known location. > -- > Christopher Head > -- > Christopher Head > _______________________________________________ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel Overall, the state of application-level isolation on desktop operating systems seems to be stuck in 1990 for some reason. Josef Gajdusek ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
