/etc/busybox.conf confusion [secutiry?]

[Jan Evert van Grootheest]

> -----Oorspronkelijk bericht-----
> Van: Jan Evert van Grootheest 
> Verzonden: vrijdag 27 april 2007 9:29
> Aan: Jan Evert van Grootheest; busybox at busybox.net
> Onderwerp: RE: /etc/busybox.conf confusion [secutiry?]
> 
> 
> All,
> 
> I think this got introduced in applets.c:check_suid with 
> 17508 'accumulated post-1.4.0 fixes'.
> 
> This part of the diff seems responsible.
> -			if ((sct->m_mode & (S_ISGID | S_IXGRP)) 
> == (S_ISGID | S_IXGRP)) {     /* *both* have to be set for sgid */
> -				xsetgid(sct->m_gid);
> -			} else xsetgid(rgid);                /* 
> no sgid -> drop */
> -
> -			if (sct->m_mode & S_ISUID) xsetuid(sct->m_uid);
> -			else xsetuid(ruid);                  /* 
> no suid -> drop */
> +			if (sct->m_gid != 0) {
> +				/* _both_ have to be set for sgid */
> +				if ((sct->m_mode & (S_ISGID | 
> S_IXGRP)) == (S_ISGID | S_IXGRP)) {
> +					xsetgid(sct->m_gid);
> +				} else xsetgid(rgid); /* no 
> sgid -> drop */
> +			}
> +			if (sct->m_uid != 0) {
> +				if (sct->m_mode & S_ISUID) 
> xsetuid(sct->m_uid);
> +				else xsetuid(ruid); /* no suid 
> -> drop */
> +			}
> 
> Previously if there was no sgid/suid, privileges would always 
> be dropped. Now they're only dropped if the uid/gid in 
> bb.conf is not 0.
> 
> I would propose to revert this part of the patch.
> Adding an else to call xsetuid/xsetgid would seem to do the 
> right thing but, I guess, would only increase the size of the 
> executable.
> 
> This seems, by the way, to be a security bug? It leaves 
> processes with effective root all over!
> 
> -- Jan Evert
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: busybox-bounces at busybox.net
> > [mailto:busybox-bounces at busybox.net] Namens Jan Evert van Grootheest
> > Verzonden: vrijdag 27 april 2007 9:07
> > Aan: busybox at busybox.net
> > Onderwerp: /etc/busybox.conf confusion
> > 
> > 
> > Hi,
> > 
> > The confusion is mine (not bb).
> > 
> > If I have sh not in /etc/busybox.conf and I login as user 
> mysql I get
> > this:
> > 
> > viking-be# cat /proc/self/status | egrep "id:|Name"
> > Name:   sh
> > Tgid:   1192
> > Pid:    1192
> > PPid:   1173
> > TracerPid:      0
> > Uid:    500     500     500     500
> > Gid:    500     500     500     500
> > viking-be# cat /proc/1173/status | egrep "id:|Name"
> > Name:   sh
> > Tgid:   1173
> > Pid:    1173
> > PPid:   1064
> > TracerPid:      0
> > Uid:    500     500     500     500
> > Gid:    500     500     500     500
> > 
> > 
> > Now, when I put sh in the busybox.conf file as using
> > sh      = xxx 0.0
> > And login again and try the same this is the result viking-be# cat 
> > /proc/self/status | egrep "id:|Name"
> > Name:   sh
> > Tgid:   1206
> > Pid:    1206
> > PPid:   1203
> > TracerPid:      0
> > Uid:    500     0       0       0
> > Gid:    500     0       0       0
> > viking-be# cat /proc/1203/status | egrep "id:|Name"
> > Name:   sh
> > Tgid:   1203
> > Pid:    1203
> > PPid:   1064
> > TracerPid:      0
> > Uid:    500     0       0       0
> > Gid:    500     0       0       0
> > 
> > 
> > I am confused, because I was expecting the same output. I
> > thought that xxx meant that the applet is a regular 
> > executable that doesn't change effective uid and gid. But 
> > apparently it does?
> > 
> > So can anyone explain this?
> > Which part of the process do I not understand?
> > My guess would be that the problem, if at all, is with the
> > starting shell, because busybox is suid root and bb.conf is 
> > read during startup.
> > 
> > This is a login via the bb telnetd (which is, of course, running as
> > root) and using the bb login (which is xxx in busybox.conf).
> > And it concerns bb 1.4.1 (with all patches, as far as I know) 
> > using glibc 2.3.6 on i386.
> > 
> > Also note the 'Name' of cat. It is 'sh'. I would guess this
> > to be due to cat being a safe applet.
> > 
> > Many thanks,
> > Jan Evert
> >  


I think more changes are needed. Passwd and su are not really behaving
well:

I'm now trying to change the password of a regular user (mysql).
If I have the passwd applet in bb.conf as xxx it, obviously, is not able
to read /etc/shadow.
If I have the passwd applet in bb.conf as sxx then it attempts to change
the password of root.
If I have the passwd applet in bb.conf as sxx and attempt 'passwd mysql'
when logged in as mysql, then the correct password is changed, but
without asking for the old password!

Something comparable is happening to the su applet. When executed as a
regular user:
With su as xxx, it asks for the password and then fails to set groups.
With su as sxx, it doesn't ask for the password and drops straight into
a shell with the correct user (just as if root had executed it).

Any ideas?

Thanks,
Jan Evert 
 
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. Vialis is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.