[PATCH] Out of bounds signature access with 32 bit off_t

[PATCH] Out of bounds signature access with 32 bit off_t

[Tobias Stoeckmann]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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(-)

diff --git a/libkmod/libkmod-signature.c b/libkmod/libkmod-signature.c
index 5ed5973..bced8ab 100644
--- a/libkmod/libkmod-signature.c
+++ b/libkmod/libkmod-signature.c
@@ -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;
-- 
2.3.0


[-- Attachment #2: 32sig.ko --]
[-- Type: application/octet-stream, Size: 336 bytes --]

Re: [PATCH] Out of bounds signature access with 32 bit off_t

[Lucas De Marchi]

On Sat, Feb 14, 2015 at 9:35 PM, Tobias Stoeckmann
<tobias@stoeckmann.org> wrote:
> 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.

> 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

Re: [PATCH] Out of bounds signature access with 32 bit off_t

[Tobias Stöckmann]

Hi,

> On February 15, 2015 at 12:43 PM Lucas De Marchi <lucas.de.marchi@gmail.com>
> 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.

> > 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.

> 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

Re: [PATCH] Out of bounds signature access with 32 bit off_t

[Lucas De Marchi]

On Sun, Feb 15, 2015 at 11:52 AM, Tobias St=C3=B6ckmann
<tobias@stoeckmann.org> wrote:
> Hi,
>
>> On February 15, 2015 at 12:43 PM Lucas De Marchi <lucas.de.marchi@gmail.=
com>
>> 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
> (which of course does not interact with the kernel) can be directed to ot=
her
> parts of the memory, which an attacker _might_ use to trigger other effec=
ts --
> with the user permission of modinfo caller.
>
> Crashing is the best thing to happen, but I haven't investigated this fur=
ther.
> 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 invest=
igate
> here.
>
>> > 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 modul=
e, it
> does.

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

>> 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
> 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