bashing your head against nation-state social engineering

Troy Benjegerdes hozer at hozed.org
Sun Sep 28 08:53:39 PDT 2014


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.

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 <tbiehn at gmail.com>
> >To: Lodewijk andré de la porte <l at odewijk.nl>
> >Cc: "cypherpunks at cpunks.org" <cypherpunks at cpunks.org>
> >Subject: 
> >Message-ID:
> >    <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg at 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 <l at odewijk.nl>
> >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'                  hozer at hozed.org
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




More information about the cypherpunks mailing list