If there's nothing else, except fixing sources of vunerable programs,
it IS correct workaround - in conjunction with symlink fix it prevents
TYPICAL, frequently exploited race conditions. Regular file race
condition can't be easily stopped, but it's usually ignored, because
these races are usually ineffective. People are using symlink fix and
they feel safe, vendors ignores that problems, or just they're fixing
these problems very slowly...
>Anything which is created non-atomically has problems. Not just with
>symbolic links, not just with fifos.
>[...]
>I bet someone could write an exploit which modifies the
>compiler's intermediate files and inserts trojan code automatically.
But MAINLY symbolic|hard links and fifos are used. Symlink/fifo
condition may be exploited easily, even manually. Regular files
condition sometimes may be exploited 'in the fly', but generally
they needs even more skillful and extremally quick exploits (in
this case, you must fit in the short time interval AFTER cc1
finished it's work and wrote results, but BEFORE gcc starts reading).
>Yes, it's a race. (I would suggest cpp files since they contain much
>blank space which can be compacted to make room for trojan code).
Right, IT IS A RACE. But fifo exploit isn't race in strict meaning
of this term - it usually have more than second to create fifo, and
then unlimited amount of time to waste - gcc will wait patiently ;)
> I'm sorry, but there just isn't a way around the problem.
Right, there's no general workaround for race conditions. But there
ARE workarounds for fifo/symlink races... And these two techniques
are usually used.
_______________________________________________________________________
Micha³ Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.pl]
Iterowaæ jest rzecz± ludzk±, wykonywaæ rekursywnie - bosk± [P. Deustch]
=--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=