Add advisory for stack buffer overflow with whoami#1911
Conversation
Shnatsel
left a comment
Shnatsel
left a comment
There was a problem hiding this comment.
Thanks for the report! Just a few minor tweaks and it's ready to go!
| [affected] | ||
| # Solaris is also probably affected, as are other Unix OSes that aren't any of: | ||
| # linux, macos, freebsd, dragonfly, bitrig, openbsd, netbsd | ||
| os = ["illumos"] |
There was a problem hiding this comment.
| os = ["illumos"] | |
| os = ["illumos","solaris"] |
FYI the full lists of recognized platforms can be found at https://docs.rs/platforms/latest/platforms/target/enum.OS.html
There was a problem hiding this comment.
Thanks. I just wasn't sure whether Solaris is affected because I don't have access to their man pages or a running machine.
From https://docs.rs/platforms/latest/platforms/target/enum.OS.html I can't tell what the other Unix platforms are.
I'm also unsure whether the other Apple platforms (iOS, tvOS, watchOS?) are affected. They would probably be affected if it was possible to build and run binaries with whoami on them, but I don't know if that's the case in reality.
There was a problem hiding this comment.
I'll add Solaris because the preponderance of evidence suggests it is affected.
There was a problem hiding this comment.
The platforms crate doesn't expose the unix-ness right now, even though rustc is aware of it. So I've written a shell script to list all Unix OSs:
rustc --print=target-list | while read TARGET; do rustc --print=cfg --target="$TARGET" | grep -q 'unix' && rustc --print=cfg --target="$TARGET" | grep 'target_os' | cut -d '=' -f 2-; done | sort -uThis is the result:
"aix"
"android"
"dragonfly"
"emscripten"
"espidf"
"freebsd"
"fuchsia"
"haiku"
"horizon"
"hurd"
"illumos"
"ios"
"l4re"
"linux"
"macos"
"netbsd"
"nto"
"openbsd"
"redox"
"solaris"
"tvos"
"vita"
"vxworks"
"watchos"
There was a problem hiding this comment.
Ahh, so some of those of those platforms would also be affected and I guess the advisory may need to be updated. Any platform where the passwd struct doesn't match Linux's, and isn't part of the other named list of platforms, is affected.
I went through a few of them by hand:
- AIX is accidentally okay because the passwd struct matches Linux.
- Fuchsia is okay, I think? I can't find the source code but this struct has all the fields, though they're in alphabetical order.
- Android is okay per this struct.
It's hard to go through every single platform, so if you have suggestions for a better way to do this, or some kind of other catch-all, I'd love that.
There was a problem hiding this comment.
The advisory db format doesn't support platform selectors, only a list.
Sadly I am not aware of a resource that would aggregate and/or diff the C APIs from different platforms.
|
Would it be important to note that this doesn't affect whoami < 0.5.3 (from 5 years ago)? This is also a problem on freebsd, dragonfly, bitrig, openbsd, netbsd with whoami >= 0.5.3, < 1.0.1 (not sure if that would count separately from this or not). |
|
Also just noticed this affects not only |
|
Yes, that would be useful. We have the |
|
Thanks. I'll send an update shortly. |
Add information about more platforms affected, per rustsec#1911 (comment).
* update RUSTSEC-2024-2020 with additional information Add information about more platforms affected, per #1911 (comment). * fix syntax * update affected.os * remove bitrig
This builds on rustsec#2193 by listing all Unix-like target operating systems as affected (since a category of OSes like "unix" cannot currently be represented in RUSTSEC advisory metadata). The list was obtained by running the command given in: rustsec#1911 (comment) The vulnerability is specific to Unix-like operating systems because: - The vulnerable code runs only in the `unix` build configuration. - 0777 permissions are meaningful on such systems and (due to containing 0002) allow any user account on the system to write. Therefore, if there are any Unix-like systems where Unix-style filesystem permissions are not used, or that are *truly* single user (i.e. do not use multiple user accounts, not even for running daemons with limited privileges), then this vulnerability would not affect such systems. In addition, I have not attempted specifically to run the proof of concept for the vulnerability on most of the listed operating systems, nor examined whether `gix-worktree-state` might not be usable on some of them for reasons unrealted to this vulnerability. Conversely, if new target OSes are added in the future, and they are Unix-like, then they would probably be vulnerable, even though not listed here. (It may not be likely that anyone would be using an affected version of `gix-worktree-state` by that time, though.)
This builds on #2193 by listing all Unix-like target operating systems as affected (since a category of OSes like "unix" cannot currently be represented in RUSTSEC advisory metadata). The list was obtained by running the command given in: #1911 (comment) The vulnerability is specific to Unix-like operating systems because: - The vulnerable code runs only in the `unix` build configuration. - 0777 permissions are meaningful on such systems and (due to containing 0002) allow any user account on the system to write. Therefore, if there are any Unix-like systems where Unix-style filesystem permissions are not used, or that are *truly* single user (i.e. do not use multiple user accounts, not even for running daemons with limited privileges), then this vulnerability would not affect such systems. In addition, I have not attempted specifically to run the proof of concept for the vulnerability on most of the listed operating systems, nor examined whether `gix-worktree-state` might not be usable on some of them for reasons unrealted to this vulnerability. Conversely, if new target OSes are added in the future, and they are Unix-like, then they would probably be vulnerable, even though not listed here. (It may not be likely that anyone would be using an affected version of `gix-worktree-state` by that time, though.)
3 participants
See:
Questions: