Hobbit monitor: Security issue with Hobbit 4.2-beta client
list Henrik Størner
I was just notified by a Hobbit user that the current beta client has
a security problem in the client "logfetch" utility, when installed as
suid-root (which is the default if "make install" is executed as root).
Impact
The effect of this is that any user who is able to login and create
files on a system with the Hobbit client installed, can use the "logfetch"
utility to get read access to any file on the system.
Which versions are affected
This issue affects all of the pre-release (alfa-, beta- and snapshot-versions)
of the Hobbit client version 4.2 released until today (2006-Jun-30), when the
client was installed as root and ~hobbit/client/bin/logfetch is suid-root.
The 4.1.x releases of the Hobbit client does not include the "logfetch"
utility, and are therefore NOT affected by this.
Remedy
It is recommended that you remove the suid bit from the logfetch utility
on systems where you have installed the Hobbit 4.2-beta client package.
To do this:
chmod 755 ~hobbit/client/bin/logfetch
Note that this may cause logfile monitoring to break, if the client does
not have read access to the monitored logfiles.
Running logfetch as suid-root will most likely be removed in the final
Hobbit 4.2 release of the client.
Regards,
Henrik Storner, the Hobbit developer
list Asif Iqbal
▸
On Fri, Jun 30, 2006 at 06:47:25PM, Henrik Storner wrote:
I was just notified by a Hobbit user that the current beta client has
a security problem in the client "logfetch" utility, when installed as
suid-root (which is the default if "make install" is executed as root).
Impact
The effect of this is that any user who is able to login and create
files on a system with the Hobbit client installed, can use the "logfetch" utility to get read access to any file on the system.
Which versions are affected
This issue affects all of the pre-release (alfa-, beta- and snapshot-versions) of the Hobbit client version 4.2 released until today (2006-Jun-30), when the client was installed as root and ~hobbit/client/bin/logfetch is suid-root.
The 4.1.x releases of the Hobbit client does not include the "logfetch"
utility, and are therefore NOT affected by this.
Remedy
It is recommended that you remove the suid bit from the logfetch utility
on systems where you have installed the Hobbit 4.2-beta client package.
To do this:
chmod 755 ~hobbit/client/bin/logfetch
Note that this may cause logfile monitoring to break, if the client does
not have read access to the monitored logfiles.For our systems we make sure if a log file needs to be monitored, it is atleast readable by a group in which `hobbit' user belongs to.
Running logfetch as suid-root will most likely be removed in the final Hobbit 4.2 release of the client.
I like that
Regards, Henrik Storner, the Hobbit developer
-- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu "..there are two kinds of people: those who work and those who take the credit...try to be in the first group;...less competition there." - Indira Gandhi
list Jason Chambers
Can you please verify this for me. This only affects if a user is able to login to the system, and not the services that may be installed on the computer. (ie ftp, web) Jason Chambers IT Helpdesk Support Geosoft Inc. XX Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: XXX-XXX-XXXX x344 Fax: XXX-XXX-XXXX www.geosoft.com -----Original Message----- From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: June-30-06 12:47 PM To: user-ae9b8668bcde@xymon.invalid Cc: user-31496adb6da5@xymon.invalid; user-9cb71ab0f763@xymon.invalid Subject: [hobbit] Hobbit monitor: Security issue with Hobbit 4.2-beta client
▸
I was just notified by a Hobbit user that the current beta client has a
security problem in the client "logfetch" utility, when installed as
suid-root (which is the default if "make install" is executed as root).
Impact
The effect of this is that any user who is able to login and create
files on a system with the Hobbit client installed, can use the
"logfetch"
utility to get read access to any file on the system.
Which versions are affected
This issue affects all of the pre-release (alfa-, beta- and
snapshot-versions) of the Hobbit client version 4.2 released until today
(2006-Jun-30), when the client was installed as root and
~hobbit/client/bin/logfetch is suid-root.
The 4.1.x releases of the Hobbit client does not include the "logfetch"
utility, and are therefore NOT affected by this.
Remedy
It is recommended that you remove the suid bit from the logfetch utility
on systems where you have installed the Hobbit 4.2-beta client package.
To do this:
chmod 755 ~hobbit/client/bin/logfetch
Note that this may cause logfile monitoring to break, if the client does
not have read access to the monitored logfiles.
Running logfetch as suid-root will most likely be removed in the final
Hobbit 4.2 release of the client.
Regards,
Henrik Storner, the Hobbit developer
list Henrik Størner
▸
On Fri, Jun 30, 2006 at 02:30:47PM -0400, Jason Chambers wrote:
Can you please verify this for me. This only affects if a user is able to login to the system, and not the services that may be installed on the computer. (ie ftp, web)
Correct. To exploit this, you must be able to create a file on the system, and run the logfetch command with a special commandline option. Regards, Henrik
list Charles Jones
▸
Asif Iqbal wrote:
For our systems we make sure if a log file needs to be monitored, it is atleast readable by a group in which `hobbit' user belongs to.
Same here, and in some installations, root access just plain isn't available.
▸
Running logfetch as suid-root will most likely be removed in the final Hobbit 4.2 release of the client.I like that
Agreed. Everything (except hobbitping?) should be non-suid by default, and even if hobbitping remains suid, "make install" should not get a critical error if it cannot perform the chown and chmod of it. Perhaps there could be a blurb in the docs to remind folks to make sure that monitored logfiles need to be readable by the hobbit user or group, and leave SUID-ing logfetch up to the user, at their own risk.