Bugtraq mailing list archives
BOOTP/DHCP security
From: itudps () ntx city unisa edu au (itudps)
Date: Wed, 27 Nov 1996 14:11:53 +1030
Many networks rely more and more on BOOTP and DHCP protocols, not just for the address discovery but the other info that optionally goes along with it. Apple, Microsoft and Unix sites are all moving to them. So what solutions have other people thought about/implemented to cope with the possibility of rogue address discovery servers being set up? Since the requests are broadcast, and OS+daemon can fit on a floppy disk in some cases and is just a free add-on in others, it is very easy to offer back incorrect, or worse still subtly incorrect information. Especially if the real server is fairly heavily loaded and may not respond as quickly as someone's desktop P150 temporarily running a free BOOTP/DHCP daemon under just about any OS you like. At least this isn't a hack people can do from outside an organisation by default, unless BOOTP forwarding has been turned on in the gateway. Examples of bogus information might include: o a new gateway that bounces everything to the real gateway but also keeps a copy of certain information, this would often be undetected in a typical large and busy commercial or educational network. o a different tftp host (sa parameter) that returns a hacked bootimage, the original having been got for free via tftp. o an incorrect subnetmask or equivalent that stops the machine working and if the bogus server only answers once a day the evidence will be gone as soon as the user restarts. Nuisance value but it would take a while to track down. o dud replies to DHCP lease information: a premature expiry will cause Microsoft stacks to freeze and if the source IP for this was forged then the logs would indicate the original DHCP server did the damage. Very, very annoying. This is particularly relevant to the relatively small number of sites that do a lot of remoteboot for security reasons (see http://lux.levels.unisa.edu.au/pub/doc/RemoteBoot.txt) but as I have shown there are other bad things that can be done as well. -- Dan Shearer email: Dan.Shearer () UniSA edu au Information Technology Unit Phone: +61 8 302 3479 University of South Australia Fax : +61 8 302 3385
Current thread:
- Digital FW2.0 question, (continued)
- Digital FW2.0 question Peter Dieth (Nov 26)
- Re: Digital FW2.0 question Alan Cox (Nov 27)
- Re: FreeBSD Security Advisory: FreeBSD-SA-96:18.lpr Warner Losh (Nov 26)
- XMCD v2.1 released (was: Security Problems in XMCD) Xmcd Admin (Nov 25)
- Security Problems in XMCD 2.1 David J. Meltzer (Nov 26)
- Re: Security Problems in XMCD 2.1 Theo Van Dinter (Nov 26)
- Re: Security Problems in XMCD 2.1 Jim Dennis (Nov 26)
- Re: Security Problems in XMCD 2.1 Alan Cox (Nov 27)
- Administratriva Aleph One (Nov 26)
- A security issue of a different kind. Alan Brown (Nov 26)
- BOOTP/DHCP security itudps (Nov 26)
- Re: BOOTP/DHCP security Alan Cox (Nov 27)
- Re: A security issue of a different kind. Jon Peatfield (Nov 27)
- Re: A security issue of a different kind. Piete Brooks (Nov 27)
- Major Security Vulnerabilities in Remote CD Databases David J. Meltzer (Nov 26)
- Re: Major Security Vulnerabilities in Remote CD Databases itudps (Nov 26)
- lquerypv fix Troy Bollinger (Nov 25)
- HP Bug of the Week! Aleph One (Nov 23)
- HP Bug of the Week: OFS Aleph One (Nov 23)
- Serious BIND resolver problem. Oliver Friedrichs (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Alan Cox (Nov 19)