[10413] in bugtraq
Re: Possible Linuxconf Vulnerability
daemon@ATHENA.MIT.EDU (Desync)
Sat May 1 13:41:44 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <372ADB4E.11C469CA@nwlink.com>
Date: Sat, 1 May 1999 03:45:34 -0700
Reply-To: desync@nwlink.com
From: Desync <desync@NWLINK.COM>
X-To: The Nefarious Type <prestochango@ANTIONLINE.COM>
To: BUGTRAQ@NETSPACE.ORG
Where do you draw the line between poor system managment and exploitable
programs. If I set suid root on /bin/bash, is that to say its an
exploit?
Obviously, someone would have to remove clock for this to occur. Which
would conclude that either A) you had incorrect permissions for clock B)
they had allready used some means of another true exploit to cause other
program to misbehave.
If someone really wanted to do some damage with physical access to a
machine, popping a rescue disk set into the drive and rebooting with the
reset switch would do fine.
The Nefarious Type wrote:
>
>
> An older version of linuxconf was packaged with Redhat 5.1 and I had
> not run into any problems with that version. But after installing the latest
> version (linuxconf-1.13r15-1) onto OpenLinux 1.3, I came upon a problem during
> boot. It had not detected /sbin/clock, so a menu appeared during boot and asked
> if I wanted to change this. This happened all before I was even prompted for a
> login.
> The fact that someone who has physical access to the server can
> access linuxconf (which by default, can only be used under root) is kind of
> disturbing. So far, I have not been able to exploit this problem, though I'm
> guessing that it could be done (e.g. from that menu, access user configuration,
> etc.).
>
> Linuxconf Homepage
> http://www.solucorp.qc.ca/linuxconf/
>
> -PrestoChango
--
---------------------{*}-----------------------
The sand castle is being washed out by the sea.
-----------------------------------------------
