User: Password:
|
|
Subscribe / Log in / New account

KS2012: Module signing

KS2012: Module signing

Posted Sep 7, 2012 10:14 UTC (Fri) by etienne (guest, #25256)
Parent article: KS2012: Module signing

I am not sure to understand why interpreting the content of an ELF file looks so difficult.
I did so in my boot-loader, and it was far to be difficult - I even handled 32 or 64 bits ELFs without too much coding (I am limited in both code and data space in a real mode boot-loader).
I have to say I did not use standards ELF libraries, just re-coded the stuff based on the fields present in the files.
Obviously my code is not made for this kind of problem, but ELF sections is very simple stuff to redo by hand.
Most of the ELF code in that boot-loader is for 32/64 bits relocation, I assume module verification is done before relocation so it is not needed.
Once you get the different sections of the ELF, you can just sign the relevant parts (i.e. not the symbols) and you do not have a problem with stripped modules.


(Log in to post comments)

KS2012: Module signing

Posted Sep 7, 2012 13:37 UTC (Fri) by jake (editor, #205) [Link]

> I am not sure to understand why interpreting the content of an ELF
> file looks so difficult.

I don't know that anyone thought it was difficult, exactly, just that it added more code to a path where a bug could be disastrous -- which means that there is more code that needs a *lot* of scrutiny. A malicious module with hand-crafted ELF could then potentially subvert the module verification code.

After all, the module code *does* already have to do some ELF interpretation, but Rusty (at least) wanted to keep that code path to *after* the module's signature was verified.

jake

KS2012: Module signing

Posted Sep 11, 2012 8:14 UTC (Tue) by gdt (subscriber, #6284) [Link]

"I am not sure to understand why interpreting the content of an ELF file looks so difficult."

It's difficult if you cannot trust that the incoming file is reasonable. Remember, the attacker doesn't care if the ELF parses to something meaningful, as their goal is only to break your parser.

If you did want to use an ELF format then you'd write a new restricted function parser just to find the signatures. That would hopefully be something you could verify easily.

Using a container also makes it harder to add signatures (for example, a corporation could very well not trust all the modules which Well Known Linux Vendor signs and may add the corporation's own signing key to only the modules which it wants loaded). This implies that the parser has to have some of the ELF fields contribute to the checksum and others not contribute (eg, timestamps). Simpler -- and thus better in this security sensitive code -- to treat the file as text and to append the signatures outside of the ELF format.

KS2012: Module signing

Posted Sep 11, 2012 9:20 UTC (Tue) by etienne (guest, #25256) [Link]

> It's difficult if you cannot trust that the incoming file is reasonable.

We are talking of an header with one field indicating the offset of an array of quadruplet { offset-in-file, memory-address, size, flags }.
What is reasonable is acceptable values for what the kernel module loader uses, easily checked by your own unbreakable function.
What is generic (and re-useable) is to create another section to put a signature of everything described loadable (in flags).

If you sign the whole file (ignoring it is an ELF file), you may end up having problems of signature order (you will end up having to sign an already signed module at some point), or having to run two different PC with exactly the same distribution but different signatures.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds