bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SECURITY] important update, please upgrade!


From: Samuel Thibault
Subject: Re: [SECURITY] important update, please upgrade!
Date: Tue, 4 Jan 2022 02:30:11 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Hello,

Samuel Thibault, le dim. 02 janv. 2022 11:32:29 +0100, a ecrit:
> A very important security update is available on the mirrors, please
> upgrade as soon as you can if you have guest accounts on your system:
> 
> libc0.3=2.33-2~3
> hurd=1:0.9.git20211230-3

Here is some background. You can check for yourself with the portinfo
tool from version 1:0.9.git20211230-4.

On previous systems, a non-root user shell would typically have the
following output:

$ portinfo -v $$
[...]
     8: send file(READ|WRITE|EXEC) io(56737,5) (refs: 1)
     9: send file(READ|WRITE|EXEC) io(2,5) (refs: 1)
    10: send auth([0],[],[],[]) (refs: 2)
[...]
    24: send AUTH 
auth([1000],[1000,1000],[1000,24,25,27,29,30,44,46,104],[1000,1000]) (refs: 2)

I.e. the non-root user shell has some ports 8 and 9 which are opened
write-enabled ports to /etc/logins (inum 56737) and / (inum 2), and it
has some auth port which is authenticated as root! (in addition to its
expected non-root auth port) It's then trivial to just use it to get
root permissions.

The problem was that the exec() function was not cleaning out ports,
notably various ports being cached in programs and libraries, and so
they would leak on fork()+exec().

The issue has been there since essentially ever. Nobody thought about
it most probably just because we didn't have the extra verbosity of
portinfo to know what ports are about in a process. Now we have, and we
can now check that there are no such ports any more.

Along the way, that paves the way for implementing the lsof tool, I have
added it to the list of small hacks.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]