Strange command histories in hacked shell history

Craig Edwards brain at winbot.co.uk
Sat Dec 18 03:45:57 PST 2004


You could change the permissions on the su binary, so that only users in the wheel group can even 
execute su. that way, when a non-wheel user attempts to su to a user in the wheel group, they simply 
get permission denied.
The idea of chmod'ing your suid binaries is always good in my opinion, and will stop this from 
happening simply and easily without having to change any code.

Ed Stover wrote:
> I like the idea of being able to allow certain users to ability to
> utilize one privileged task while not granting that user the ability to
> really do damage on a system. And yes I believe that a user will exist
> in wheel when he/she/it has the knowledge and skills needed for
> accountability. Yes (I sense it coming), I also believe that properly
> utilizing the user and group functions on a FreeBSD machine is really
> the way it should be done, but what fun can be had with out bells,
> whistles and  nifty programs that do the thinking for us? Personally I
> don't trust to many to be in my wheel and my favorite practice is 
> # chflags schg files
> 
> 
> bash-3.00$ sudo echo "woohooIhavekeysforjustrestartingfaileddaemons"|
> wall &&rm -rf /etc && dd if=/dev/zero of=/var/testfile bs=1024
> count=99999999&
> v.s.
> bash-3.00# su -l root
> bash-3.00# echo "woohooIhavekeysforeverything"|wall &&rm -rf /etc && dd 
> if=/dev/zero of=/var/testfile bs=1024 count=99999999&
> 
> 
> 
> On Fri, 2004-12-17 at 22:13 -0600, Elvedin Trnjanin wrote:
> 
>>Bill Vermillion wrote:
>>
>>
>>>I understand that after using Unix for about 2 decades.
>>>
>>>However in FreeBSD a user is supposed to be in the wheel group [if
>>>it exists] to be able to su to root.
>>>
>>>But if a person who is not in wheel su's to a user who is in wheel,
>>>then they can su to root - as the system sees them as the other
>>>user.  
>>>
>>
>>>This means that the 'wheel' security really is nothing more
>>>than a 2 password method to get to root.
>>>
>>> 
>>>
>>
>>Precisely. If you don't like this then the way around is to only allow
>>a 
>>certain group access to su and none for everyone else.
>>
>>
>>>If the EUID of the orignal invoker is checked, even if they su'ed
>>>to a person in wheel, then they should not be able to su to root.
>>>
>>>I'm asking why is this permitted, or alternatively why is putting a
>>>user in the wheel group supposed to make things secure, when in
>>>reality it just makes it seem more secure - as there is only one
>>>more password to crack.
>>> 
>>>
>>
>>One more password to crack is more time which means a better chance
>>of 
>>catching the cracker in the act.  Although I don't know why exactly
>>the 
>>authors of su did that the way they did but my first and best guess 
>>would be convenience. The two password method is better than a new
>>login 
>>session each time you want to get to root. Second best guess would be
>>is 
>>that they didn't figure out that issue or at least think much of it.
>>
>>-- 
>>---
>>Elvedin Trnjanin
>>http://www.ods.org
> 
> 
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
> 
> 

-- 
WinBot IRC client developer: http://www.winbot.co.uk
ChatSpike - The users network: http://www.chatspike.net
InspIRCd - Modular IRC server: http://www.inspircd.org
Online RPG Developer: http://www.ssod.org
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20041218/080da343/signature.bin


More information about the freebsd-security mailing list