full-disclosure - Re: Symlink vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20209.1319726915@turing-police.cc.vt.edu>
Date: Thu, 27 Oct 2011 10:48:35 -0400
From: Valdis.Kletnieks@...edu
To: noloader@...il.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Symlink vulnerabilities

On Thu, 27 Oct 2011 09:51:33 EDT, Jeffrey Walton said:
> On Thu, Oct 27, 2011 at 9:43 AM, xD 0x41 <secn3t@...il.com> wrote:

> > You try to change and fiddle here, it would need alot better than just
> > the current shell scripting, and, even then, i dnt think it would win
> > the race conditiobn.
> See Bishop and Dilger's paper:
> nob.cs.ucdavis.edu/bishop/papers/1996-compsys/racecond.pdf

The other thing that people need to remember is that there's no race condition
that's so small that you can't hit it.  If there's a race condition, it *can*
be won.  A while back, a bug was found in the Linux kernel that caused an I/O
driver to hang - it got debugged because one guy's machine was tripping over it
*totally by accident* every few weeks.  It turned out that the timing hole was
aboud *3 instructions wide* (two lines of code were reversed, allowing an
interrupt to happen one line earlier than was actually safe).  Yes - at 3.2Ghz,
you're looking at a hole *literally* about a billionth of a second wide
 - and this guy was hitting it accidentally every 2 weeks or so.

And for userspace races, it's usually pretty easy to increase the size of the
hole by waiting till just before the hole begins, then spawning a whole bunch
of processes that just do 'for(;;)' (or possibly a syscall in a tight loop,
depending on the details) - basically just spike the load average way up.  This
will overwhelm the scheduler (note that with proper timing, none of the just
forked processes will accumulate enough time for the scheduler to relabel them
as cycle-suckers and will still look "interactive" and likely to schedule).
Hopefully this gets you scheduled into the timing hole.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/