| |||||||||||||
KS2012: Module signingKS2012: Module signingPosted Sep 11, 2012 8:14 UTC (Tue) by gdt (subscriber, #6284)In reply to: KS2012: Module signing by etienne Parent article: KS2012: Module signing
"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.
(Log in to post comments)
KS2012: Module signing Posted Sep 11, 2012 9:20 UTC (Tue) by etienne (subscriber, #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 }.
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.
|
|||||||||||||