10-year-old Sudo bug lets Linux users gain root-level access

[Flash]

Ha ha, once again Puppy proves its superiority. Puppy is already root!
https://www.zdnet.com/article/10-years- ... el-access/

The vulnerability, named "Baron Samedit," impacts most Linux distributions today.
A major vulnerability impacting a large chunk of the Linux ecosystem has been patched today in Sudo, an app that allows admins to delegate limited root access to other users.

The vulnerability, which received a CVE identifier of CVE-2021-3156, but is more commonly known as "Baron Samedit," was discovered by security auditing firm Qualys two weeks ago and was patched earlier today with the release of Sudo v1.9.5p2.

In a simple explanation provided by the Sudo team today, the Baron Samedit bug can be exploited by an attacker who has gained access to a low-privileged account to gain root access, even if the account isn't listed in /etc/sudoers — a config file that controls which users are allowed access to su or sudo commands in the first place....

[user1111]

Ha ha, once again Puppy proves its superiority. Puppy is already root!

Hmm! Hi Flash. That does however strike as being somewhat "front door lock insecurity issues doesn't matter coz we leave the door wide open anyway". The blessing is that being remote enough - more often you get away with it. In my childhood years the area we lived in and it was very common to live like that, I guess because most had little worth stealing anyway and what one did acquire would more often be shared around. My grandfather for instance was a great fisherman and natural resources individual, and a bountiful catch would have us walking into neighbours houses on the way home to leave a salmon (or rabbits, or mushrooms ..whatever) on their table. That also worked the other way around and sometimes you'd go out into the back garden, and on returning into the pantry there'd be a surprise on the table, a nameless gift (but more often you knew had been in and left it).

By coincidence, the other day another group I partake were discussing timing type methods to elevate to root - somewhat Spectre/Meltdown style. Probabilistic brute forcing root passwords. Basically by trying a password with each letter in turn and where response times potentially indicated the right character. For a password of woofwoof for instance trying wa could respond slower than trying za due to string compare matching the first character in one case and going on to compare the next character, whereas the za case fails at the first character failing to compare to the actual password and as such reports the failure quicker. Having tried the entire 'alphabet' (upper/lower case, numbers, symbols etc.) and deduced the probable first character of the password as being 'w' ... that is repeated all over again for the next character 'wa, wb ..... etc, and where wo takes the longest to reject due to it going on to test the third character rather than failing at the second character ...etc.

In times past there were smaller communities, and few attacking (or inclined to attack) others. Nowadays with a global community so potential victims are massively more accessible and as such has also expanded the numbers and methods of attacks. And where those that do get in are less inclined to leave you a pleasant gift.

[s243a]

By coincidence, the other day another group I partake were discussing timing type methods to elevate to root - somewhat Spectre/Meltdown style. Probabilistic brute forcing root passwords. Basically by trying a password with each letter in turn and where response times potentially indicated the right character.

This would seem to be a flaw in the password design. I would have expected a password system to compare the hashes of the password rather than a comparison of the actual password. If comparisons were done on hashes then I think that said technique wouldn't work.

[rockedge]

Also more on the exploit:
https://www.openwall.com/lists/oss-secu ... 21/01/26/3

[Clarity]

The "SUDO" command is a part of every PUP since the beginning, it appears.

Is there a way, currently, to disable the sudo command use in the terminal once booted?

I am aware that a new PUP would have to be developed for "ROOT ONLY" user system without "sudo" in its console.

Any insights welcomed.

[s243a]

The "SUDO" command is a part of every PUP since the beginning, it appears.

Is there a way, currently, to disable the sudo command use in the terminal once booted?

I am aware that a new PUP would have to be developed for "ROOT ONLY" user system without "sudo" in its console.

Any insights welcomed.

Fatdog uses su to emulate sudo. Tinycore seperates busybox into two binaries which are those that require root and those that don't. Anyway, rather than relying on user permissions for security you can run a root user in a container with capabilities dropped. See:

viewtopic.php?f=60&t=1915

[user1111]

rather than relying on user permissions for security you can run a root user in a container with capabilities dropped. See:

viewtopic.php?f=60&t=1915

My latest revision viewtopic.php?p=16475#p16475 of that now uses 'puppy space' to aufs mount the changes (where all changes are stored i.e. similar to save folder space), main sfs (fd64.sfs in my case) and where the top (layered) view are stored/used. Instead of using a hdd ext folder. So now additionally leaves no fingerprints (i.e. otherwise ext 3/4 journalling can facilitate recovery of even shredded files/folder contents).

Runs well enough for me to have it as my default desktop i.e. Fatdog boots and in ~/Startup I have it start that 'container'

Separate X server (Xephyr), and where root can't even cd to /home/spot, let alone access the main systems data ...etc. In effect root in name only, but that is more like a highly restricted userid. And operationally just as fast as if running a native (full root) Fatdog desktop.

Having two desktops (Fatdogs Openbox in my case for the main session, jwm for the contained session) that are both 'full screen' is nice (i.e. Xephyr (contained) system also full screened so it looks just like a regular desktop), but does mean that it can get confusing as to which desktop the keyboard and mouse are focused to. With a Xephyr window you see the mouse 'hit the wall' of the windows borders and the window title indicates that focus is locked (or not), when full screened however that visibility is lost. Accordingly I created some functionality that shows that status in the tray, a simple ball icon that is coloured blue if locked, green if unlocked (and where the standard ctrl shift Xephyr defined keys toggles that). For instance when locked then alt-tab will step between windows within the Xephyr (contained) desktop only, when unlocked then alt-tab steps between the main sessions windows, of which the Xephyr 'window' is just one. That mouse/keyboard locked/unlocked state has no bearing on security however, either way a hacker even with full root control within the Xephyr session cannot get-to/access the main system. In effect the mouse and keyboard are 'owned' by the main session/real root, and any attempts to access/control that from within the container is blocked (for instance running xdotool to enter the ctrl-shift control sequence from within the Xephyr session results in no action actually occurring), nor can the contained session 'get to' the keyboard/mouse devices (as they're within the main sessions (real root) control).

When the contained session desktop is good enough for general usage, there's little need to switch over to the real root main desktop, other than for shutting down or reconfiguring things ...etc. I however prefer to ssh out from that real/main session as I don't download/run anything across/using ssh and I'd rather keep my ssh keys within the main system rather than including them in the contained system. Similarly wifi net connecting in the main session is appropriate IMO as then the contained system can't get to see the likes of ssid and passwords used (that the system by default preserves for each session in case the wifi link disconnects - so it can reconnect automatically). And of course storing data within the main session is appropriate, just use the shared folder as a gateway for which files are moved to/from the contained session.