linux-kernel - Re: RFC: sign the modules at install time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyDW4z5x8YcbQ8CYJvwHE3poK9iX8Sfgbg2fVaS3Bio4w@mail.gmail.com>
Date:	Fri, 19 Oct 2012 15:04:03 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	David Miller <davem@...emloft.net>,
	David Howells <dhowells@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: RFC: sign the modules at install time

On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
> probably really should try to make that sign-file and x509keyid merge.
> My fix made the thing even slower, doing two extra "wc -c" invocations
> since it can't do "${#..}" expansion due to the locale problem.

Hmm. I haven't seen this breakage personally yet, but looking more at
Rusty's last changes I'm pretty sure my fixes are potentially not
sufficient.

In particular, this line from Rusty's sign-file script simplification
makes me worry:

  KEYID="`perl $keyid_script $x509 keyid`"

and the problem is that the 'keyid' is a binary blob.

And I'm pretty damn sure that assigning random binary data to shell
variables is going to break eventually. In particular, I tested NUL
characters, and bash is not happy about doing things like

   a="`echo -en '\000'`"

and 'a' ends up empty, not containing a one-byte string containing a
NUL character. Not to mention that even if the shell were to handle
this correctly, if you do

  echo -n "$a"

then even *if* the shell remembered that 'a' contains one NUL
character, when it then executes the 'echo' binary, that will
certainly not be able to handle it. With a built-in 'echo' it _could_
work, with an external one it fundamentally could not. NUL is special,
and terminates strings at execve(). You cannot have NUL bytes in
arguments.

Of course, I don't know the rules for x509 key id blobs. Maybe they
aren't allowed to contain NUL anyway?

Possible solutions:

 - Linus is a worry-wart, and key id's never contain NUL.

 - somebody with the appropriate perl-fu does the perl conversion, and
keeps it all in perl.

 - somebody with (slightly less) perl-fu makes the x509 keyid_script
return a quoted string, so that we can save that *quoted* version for
the shell interatction (perhaps in a similar format that we now use
for the "prologue" variable, ie just a list of hex bytes)

otherwise we need to go back to putting the binary blob in a file
(which shell won't corrupt).

Rusty, David?

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/