On Sun, Sep 28, 2014 at 10:53:39AM -0500, Troy Benjegerdes wrote: > Because it's a nice mirage conjured by nation-state social > engineers to get us to crawl further out into the desert? :) > > Of course, hackers with stillsuits was probably outside the > social engineering requirements doc.
If that wasn't a reference to https://www.youtube.com/watch?v=an_bnXUIP0Y before, it is now. Cheers, --mlp > On Sun, Sep 28, 2014 at 06:47:55AM -0700, Subrosa.io wrote: > > I think this vulnerability should have been discovered with any kind of > > basic fuzzing. I have little doubt that this has been discovered and has > > been exploited in the wild. > > > > How is Mirage OS promising and relevant here? > > > > ---- On Sat, 27 Sep 2014 14:48:24 -0400 Travis Biehn wrote ---- > > >From: Travis Biehn <[email protected]> > > >To: Lodewijk andré de la porte <[email protected]> > > >Cc: "[email protected]" <[email protected]> > > >Subject: > > >Message-ID: > > > <CAKtE3zcZ9LuBKvJnFm_RJ3te=motchxxdioja17291uhuvf...@mail.gmail.com> > > >Content-Type: text/plain; charset="utf-8" > > > > > >I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is > > >the best course followed for -users- of software. [in addition to all the > > >patching and whatever.] > > > > > >Developers of that software, ultimately, are responsible for securing their > > >stuff. As an aside - separating your complex system into multiple trust > > >zones, from a development standpoint, is de-rigueur for secure design. > > > > > >Security heads have long been decrying cgi-bin. Most of the reason is that > > >the threat surface is insane - for binaries you have user input that's not > > >running in some sort of VM [php,perl,ruby,node.js, etc] and existing in > > >memory entangled with executable instructions. > > > > > >Injection attacks, are, of course old-hat. The daemons could have done some > > >hand-holding in this respect before passing off headers to ENV variables. > > > > > >The issue is that 'restricted chars' wasn't defined by a standard interface > > >between daemon and cgi-bin script. The called function has a completely > > >arbitrary set of restricted chars. > > >/bin/bash, of course, isn't written to withstand env attacks - since the > > >calling user controls the env / and bash is executed under that user's > > >privileges. > > >So it is, of a matter of course, inevitable to find vulnerability there. > > >With one process isolating the client from the env, modifying the env as a > > >result of the user's whims and then passing off to a sub-process that > > >trusts the env implicitly. > > > > > >It is very unlikely that any TLA 'created' this vulnerability. The notion > > >is entirely incredible. The existence of vulnerability in such a design is > > >immediately obvious from anyone who takes more than a cursory look at it. > > >That isn't to say that this specific attack was trivial to identify - that > > >is to say from an architecture standpoint it should be evident that the > > >handoff between httpd and cgi-bin is a location of extreme vulnerability. > > > > > >On a related note: Mirage OS looks like it's on a promising tack: > > >http://www.xenproject.org/developers/teams/mirage-os.html > > > > > >-Travis > > > > > >On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte > > ><[email protected]> > > >wrote: > > > > > >> Know what you code, and what you run. Don't be fooled by words and > > >> shapes, > > >> code does what code does, that is all. > > >> > > >> We seriously need a way to detach code from mental models to expose > > >> hidden > > >> features. Basically, all computer law is rubbish because everything you > > >> run > > >> on your computer, exploits and all, is something you run by choice. But > > >> there's no way you could validate the sheer bulk of code. If you want to > > >> really solve security flaws it'll involve somehow validating the > > >> possibilities of the code run. > > >> > > >> It's a discipline that touches on visualization, automated testing and > > >> simplification. Simplification meaning, reducing possible states and > > >> "execution paths". And just making code easier to comprehend. > > >> > > >> The problem is that there's either no market for "truly secure" > > >> computing, > > >> or there's just nobody filling the gap. Banks with their Cobol are > > >> laughed > > >> at, mostly, and accused of lacking innovation. They do lack innovation in > > >> the technical field. And Cobol is definitely not an ideal language. But > > >> "truly secure" is worth a lot to them. L4 validated is a step in the > > >> right > > >> direction, but catches a lot of wind saying it's still imperfect and > > >> therefore worthless. > > >> > > >> I'm utterly bored by code review. Maybe it'd be better if there were some > > >> nicer tools to help out. I'm really sure someone has great > > >> recommendations > > >> regarding this. (That don't even require Cobol :) > > >> > > > > > > > > > > > >-- > > >Twitter <https://twitter.com/tbiehn> | LinkedIn > > ><http://www.linkedin.com/in/travisbiehn> | GitHub > > ><http://github.com/tbiehn> > > >| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus > > ><https://plus.google.com/+TravisBiehn> > > >-------------- next part -------------- > > >An HTML attachment was scrubbed... > > >URL: > > ><http://cpunks.org/pipermail/cypherpunks/attachments/20140927/fb6add10/attachment-0001.html> > > > > > > > > > -- > ---------------------------------------------------------------------------- > Troy Benjegerdes 'da hozer' [email protected] > 7 elements earth::water::air::fire::mind::spirit::soul grid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash >
