Conversation

Notices

1. Embed this notice
   Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:08:28 JST Ryan Castellucci :nonbinary_flag:

   • Dan Goodin

   @dangoodin seems like potentially "nasty surprise behavior" - some people use 0.0.0.0 in hosts files rather than 127.0.0.1 to avoid the failed connections to localhost. I can't recall why this mattered.

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:09:32 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin

     @dangoodin I can imagine DNS rebinding protections not covering 0.0.0.0 maybe?

   • Embed this notice
     Dan Goodin (dangoodin@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:11:43 JST Dan Goodin

     in reply to

     @ryanc

     So the ability of a website to send requests to 0.0.0.0 might be riskier for people who use that IP in their hosts file?

     What about people who don't use host files, or use 127.0.0.1?

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:24:24 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin

     @dangoodin I just read through the article, my take away is "programs running an http listener on localhost without authentication are an old problem that was thought to have been addressed, but a vector was missed".

     Firefox is the illustrative case here - it had no feature to protect these insecure localhost services in the first place.

     Other browsers had implemented a mitigation to prevented them from being used to exploit these kinds of services, I assume back when DNS rebinding attacks were the new hotness.

     Vulnerable localhost services were still vulnerable, and it turns out the mitigation to protect them was incomplete.

     The one angle I do see is developers thinking it's okay not to have auth on the localhost service because websites can't trigger access to it. Turns out this was a bad assumption, but it never should have been relied upon in the first place.

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:29:20 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin

     @dangoodin also, same origin policy imposes a lot of limits on how these sorts of services can be interacted with, and rebinding was mainly about bypassing same origin policy.

     Cross origin requests are limit to GET and a subset of POST requests which boil down to "requests html forms could make in the early 2000s".

   • Embed this notice
     Dan Goodin (dangoodin@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:31:03 JST Dan Goodin

     in reply to

     @ryanc

     When you put it like that ("boil down to 'requests html forms could make in the early 2000s") it sounds like there is NOT a lot of harm that can result from exploits. Am I understanding you correctly?

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:35:20 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin

     @dangoodin I honestly can remember what the 0.0.0.0 vs 127.0.0.1 thing for hosts files was.

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:43:46 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin
     • Alex Savage

     @optimant @dangoodin Yeah, anyone can make a localhost listener that has arbitrarily bad security consequences if abused. Most people won't be running those services.

   • Embed this notice
     Alex Savage (optimant@hachyderm.io)'s status on Thursday, 08-Aug-2024 03:43:47 JST Alex Savage

     in reply to

     • Dan Goodin

     @dangoodin @ryanc I mean, it's a constraint for sure (e.g. the POST will be forms-encoded instead of, say, JSON like a green developer writing a service today might write code to expect) but risk will depend on the specific target. A soft target might even be susceptible to GET alone.

     Car analogy: We discovered that leaving keys inside the car, even out of sight, is vulnerable because thieves can still use coat hangers to pop the locks. Non ignition-key mitigations like The Club are unaffected.

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 03:44:55 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin
     • Alex Savage

     @optimant @dangoodin a cross origin POST can be encoded text/plain - which can fit JSON. If the server doesn't check the content-type header...

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 08-Aug-2024 04:10:54 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Dan Goodin
     • Alex Savage

     @optimant @dangoodin A major part of my previous job was encoding data to make it fit in "text/plain" so preflight wouldn't be needed.

     One of my friends dubbed it "encraption" which is not wrong.

     I ended up writing a custom compression algorithm that output directly to text/plain without needed anything like base64 encoding, though they never used it.

   • Embed this notice
     Alex Savage (optimant@hachyderm.io)'s status on Thursday, 08-Aug-2024 04:10:55 JST Alex Savage

     in reply to

     • Dan Goodin

     @ryanc @dangoodin Oh dang I forgot about enctype. Now I'm going to be thinking about poking at other URI schemes for the form action - dredged up a memory that you used to be able to do a mailto: and try to compose an email with the local client!