Skip to contentSkip to conversation

Out of bounds signature access with 32 bit off_t

PATCH In review Tobias Stoeckmann 2 participants 4 messages Feb 14, 2015 – Feb 18, 2015

lore
Share & tools
lore

Tobias Stoeckmann

author
#0 lore raw

PATCH 1/1 Out of bounds signature access with 32 bit off_t

Hi,

if kmod has been configured with --disable-largefile on a 32 bit system, off_t will be 32 bit. In that case, the parsed sig_len can bypass a validation check (it's _unsigned_ 32 bit), allowing a an attacker to perform out of boundary access through a malicious module.

Due to the unlikeliness of people using --disable-largefile, this is a mere validation fix. With an explicit signed 64 bit cast, there is no binary change for 99.9% of Linux systems out there. ;)

Attached please find a proof of concept, which will most likely result in a segmentation fault (works fine with 64 bit off_t builds):

tobias:~$ modinfo 32sig.ko
filename:       /home/tobias/32sig.ko
Segmentation fault

Tobias

---
 libkmod/libkmod-signature.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
libkmod/libkmod-signature.c +1 -1
index 5ed5973..bced8ab 100644
@@ -124,7 +124,7 @@ bool kmod_module_signature_info(const struct kmod_file *file, struct kmod_signat
 			modsig->id_type >= PKEY_ID_TYPE__LAST)
 		return false;
 	sig_len = be32toh(get_unaligned(&modsig->sig_len));
-	if (size < (off_t)(modsig->signer_len + modsig->key_id_len + sig_len))
+	if (size < (int64_t)(modsig->signer_len + modsig->key_id_len + sig_len))
 		return false;
 
 	size -= modsig->key_id_len + sig_len;
Signature · 1 line
2.3.0
#1 lore raw
Quoted 6 lines · Tobias Stoeckmann

Hi,

if kmod has been configured with --disable-largefile on a 32 bit system, off_t will be 32 bit. In that case, the parsed sig_len can bypass a validation check (it's _unsigned_ 32 bit), allowing a an attacker to perform out of boundary access through a malicious module.

There's no "validation check" in kmod. This is done by the kernel, no the userspace tools. The fix looks correct, but not the assumption this is a security risk. modinfo is only used to get information from the module and the only bad thing that can happen is it crashing.

Quoted 6 lines

Due to the unlikeliness of people using --disable-largefile, this is a mere validation fix. With an explicit signed 64 bit cast, there is no binary change for 99.9% of Linux systems out there. ;)

Attached please find a proof of concept, which will most likely result in a segmentation fault (works fine with 64 bit off_t builds):

Is it "most likely" or is it certain to get a segfault?

Could you send the source code of this module so I can add it to the testsuite? I realize you had to poke the module after it was compiled in order to corrupt it to produce segfaults, then send the command you use, too.

thanks
Lucas De Marchi

author
#2 lore raw

Hi,

Quoted 6 lines

On February 15, 2015 at 12:43 PM Lucas De Marchi <[email protected]> wrote:
There's no "validation check" in kmod. This is done by the kernel, no the userspace tools. The fix looks correct, but not the assumption this is a security risk. modinfo is only used to get information from the module and the only bad thing that can happen is it crashing.

It's definitely not a security risk to the kernel. What I mean is that modinfo (which of course does not interact with the kernel) can be directed to other parts of the memory, which an attacker _might_ use to trigger other effects -- with the user permission of modinfo caller.

Crashing is the best thing to happen, but I haven't investigated this further. After all the range check (in modinfo) should be corrected and the issue is gone. Also, a 32 bit off_t is too unlikely to encounter to further investigate here.

Quoted 8 lines
Quoted 6 lines

Due to the unlikeliness of people using --disable-largefile, this is a mere validation fix. With an explicit signed 64 bit cast, there is no binary change for 99.9% of Linux systems out there. ;)

Attached please find a proof of concept, which will most likely result in a segmentation fault (works fine with 64 bit off_t builds):

Is it "most likely" or is it certain to get a segfault?

As written before, if the memory layout of the system is known, it doesn't have to segfault. In most cases, it will. On my system with the supplied module, it does.

Quoted 4 lines

Could you send the source code of this module so I can add it to the testsuite? I realize you had to poke the module after it was compiled in order to corrupt it to produce segfaults, then send the command you use, too.

There is no source code for these files, because I wrote them with hexedit. As I wrote them, you are free to take them for the test suite.

Tobias

#3 lore raw
Quoted 3 lines · On Sun, Feb 15, 2015 at 11:52 AM, Tobias St=C3=B6ckmann…

Hi,

Quoted 1 line

On February 15, 2015 at 12:43 PM Lucas De Marchi <lucas.de.marchi@gmail.=

com>

Quoted 7 lines
Quoted 5 lines

wrote:
There's no "validation check" in kmod. This is done by the kernel, no the userspace tools. The fix looks correct, but not the assumption this is a security risk. modinfo is only used to get information from the module and the only bad thing that can happen is it crashing.

It's definitely not a security risk to the kernel. What I mean is that mo=

dinfo

Quoted 1 line

(which of course does not interact with the kernel) can be directed to ot=

her

Quoted 1 line

parts of the memory, which an attacker _might_ use to trigger other effec=

ts --

Quoted 3 lines

with the user permission of modinfo caller.

Crashing is the best thing to happen, but I haven't investigated this fur=

ther.

Quoted 1 line

After all the range check (in modinfo) should be corrected and the issue =

is

Quoted 1 line

gone. Also, a 32 bit off_t is too unlikely to encounter to further invest=

igate

Quoted 7 lines

here.

Quoted 5 lines
Quoted 5 lines

Due to the unlikeliness of people using --disable-largefile, this is a mere validation fix. With an explicit signed 64 bit cast, there is no binary change for 99.9% of Linux systems out there. ;)

Attached please find a proof of concept, which will most likely result=

in

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

a segmentation fault (works fine with 64 bit off_t builds):

Is it "most likely" or is it certain to get a segfault?

As written before, if the memory layout of the system is known, it doesn'=

t have

Quoted 1 line

to segfault. In most cases, it will. On my system with the supplied modul=

e, it

Quoted 1 line

does.

Ok. I reworded the commit message a little bit and applied.

Quoted 6 lines
Quoted 4 lines

Could you send the source code of this module so I can add it to the testsuite? I realize you had to poke the module after it was compiled in order to corrupt it to produce segfaults, then send the command you use, too.

There is no source code for these files, because I wrote them with hexedi=

t. As I

Quoted 1 line

wrote them, you are free to take them for the test suite.

I agree with you. Unfortunately not everybody (or every distribution) agrees. If you take a look on recent commits to testsuite, I'm removing all the pre-compiled modules from there. When I finish the remaining modules I'll figure out a way to add a test for it.

thanks

--=20
Lucas De Marchi