home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / gzip.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  2.3 KB  |  52 lines
  1.  
  2. I found a bug in gzip that can allow a file that is being compressed or
  3. uncompressed to be read by anyone with search access to the directory it is
  4. in. Before unlink()ing the original file (when compressing or
  5. uncompressing), it is chmod()ed to 0777.  It looks like someone didn't
  6. understand the behavior of unlink(2) vs rm(1).
  7.  
  8. The problem code is in gzip.c, in copy_stat(), on line 1636:
  9.  
  10.     (void) chmod(ifname, 0777);
  11.     if (unlink(ifname)) {
  12.  
  13. There is also a similar bug when overwriting an existing file, in
  14. check_ofname(), on line 1576:
  15.     (void) chmod(ofname, 0777);
  16.  
  17.     if (unlink(ofname)) {
  18.  
  19. In both cases, the chmod() is not necessary, and only introduces a security
  20. hole. The solution is trivial - remove the chmod()s.
  21.  
  22. gzip will not normally touch a file with a link count greater than 1. With
  23. -f it will. If you know that a file you want to read will be gzip -f'd,
  24. that makes this easy - make a hard link to it, and wait for your link to be
  25. the only copy, mode 777.
  26.  
  27. Without -f, there are two race conditions, an easier one if you can make a
  28. hard link to the file, and a hard one if you can not. There's also a
  29. possibility for a minor denial-of-service attack, not caused by this bug.
  30.  
  31. For the denial-of-service attack, make a hard link to a file you know will
  32. be gzipped either automatically or by a person who won't understand what
  33. the "gzip: foo has 1 other link  -- unchanged" message means. This is also
  34. what happens if you make the link too early for the 'easy' race. This is
  35. not really a gzip issue, however, but does serve as yet another example of
  36. why there should be some way to restrict a user from adding links to a file
  37. he does not own.
  38.  
  39. For the hard race, open() the file in between the chmod() and the unlink().
  40. This is possible, but difficult.
  41.  
  42. For the easier race, make a hard link to the file in between the lstat()
  43. (which is before the open(), so you have the entire time it takes to
  44. compress the file) and the unlink(). The problem with this race is that if
  45. you lose, you lose for good. You get one chance, if you do it too soon,
  46. gzip complains, if you do it too late, the file is gone.
  47.  
  48. This isn't really a serious bug, but it does show that software should
  49. always be written with race conditions in mind, and that even local
  50. non-suid utilities must be written with security in mind.
  51.  
  52.