[ntp:security] Re: Concerning a possible bug in the 'ntp' package
daw at cs.berkeley.edu
Fri Sep 2 03:44:56 UTC 2005
Danny Mayer writes:
> Ben Schwarz writes:
> > (void) mktemp(res_file);
> > res_fp = fopen(res_file, "w");
> > (void)fprintf(res_fp, "%s %d %d %d %d %d %d %u %s\n", name,
> > mode, version, minpoll, maxpoll, flags, ttl, keyid, keystr);
> > The possible problem is instead of opening /tmp/ntpXXXXXXX
> > for writing, which is what the program tries to do, it may actually
> > be opening another sensitive file. For instance, an attacker
> > might predict the name of the tempfile and create
> > a symlink before ntpd opens it, and then cause log information
> > to be written to the file. This could be potentially dangerous
> > especially if an attacker can influence the contents of this
> > log information.
> Well in this instance, ntpd is opening the file for write, thereby
> overwriting any original contents so it does not matter what an attacker
> may have written into it.
I think you may have missed the point Ben Schwarz was making.
What if the adversary predicts the filename that mktemp() generates,
say /tmp/ntpd123456, and creates a symlink from /tmp/ntpd123456
to /etc/passwd? Then you're in big trouble. The call to fopen()
truncates /etc/passwd, and the call to fprintf() writes a new line there.
The truncation is already terrible, and if the attacker can control is
written, then it is doubly bad, because the attacker may be able to add a
bogus entry to /etc/passwd that gives him a password-less root account.
Of course, the adversary might not be able to write to /etc/passwd
himself, but the ntp program might be able to do so if it were running
as root. /etc/passwd was just an example, and you can imagine all sorts
of system files that it would be very bad if the adversary can truncate,
corrupt, or overwrite.
As a general note, can I encourage you to read up on filesystem
race vulnerabilities? It sounds like there is some background you
may be missing, and which is very relevant to this discussion. Here
are some pointers:
I apologize if you are already familiar with this material.
I hope this helps.
> In this case it happens to be for a DNS
> lookup. The attacker is welcome to the information if he can get it
> since then he'd have to mount a DNS attack which is a different kind of
> challenge. So you'd end up with the attacker having to deal with two
> attacks instead of one. Is it a risk? Maybe, but it would be pretty
> pointless to attack that file.
> > I don't know enough about ntpd to say whether or not this
> > is truly a bug. If it's not, we apologize.
> It's better than saying nothing. We are always looking for help to
> analyze the code so that we can do better.
> > Ben Schwarz
More information about the security