Subject: [alpine-devel] Re: [PATCH 8/8] main/syslinux: hooks for bootloader password

From: Dubiousjim <[email-masked]>
Date: Sat, 29 Jun 2013 11:49:05 -0400

On Fri, Jun 28, 2013 at 01:21:57PM -0500, William Pitcock wrote:
> On Thu, Jun 27, 2013 at 2:32 AM, Dubiousjim <[email-masked]> wrote:
> >
> > Dubiousjim (8):
> >   main/syslinux: fix/refactor initramfs
> >   main/syslinux: use more specific COM32 (instead of KERNEL) for
> >     mboot.c32
> >   main/syslinux: use more specific LINUX (instead of KERNEL) for kernels
> >   main/syslinux: reorganize menu layout
> >   main/syslinux: add reboot entry
> >   main/syslinux: add Hardware Detection Tool entry
> >   main/syslinux: don't create backup when no changes
> >   main/syslinux: hooks for bootloader password
> >
> >  main/syslinux/APKBUILD             |  1 +
> >  main/syslinux/update-extlinux      | 76 ++++++++++++++++++++++++++++----------
> >  main/syslinux/update-extlinux.conf |  9 +++++
> >  3 files changed, 66 insertions(+), 20 deletions(-)
> 
> Acked-by: William Pitcock <[email-masked]>
> 
> William

Thanks William.

> On Fri, Jun 28, 2013 at 04:54:53PM +0200, Natanael Copa wrote:
> > On Thu, 27 Jun 2013 03:32:21 -0400
> > Dubiousjim <[email-masked]> wrote:
> 
> > > +	install -D -m755 utils/sha1pass "$pkgdir"/usr/sbin/sha1pass || return 1
> > 
> > I had a look at this script but i don't like it.
> > 1) IMHO its useless use of perl. A tiny C app using crypt(3) would do
> > the same job with less lines and without perl.
> > 2) it requires that password is specified on command line. I think it
> > should at least optionally be able to read it from stdin.
> > 
> > Looks like it supports sha256/sha512 passwords. Maybe we could use
> > cryptpw instead?
> > 
> > Could you please test if the cryptpw generated passwd works? If so,
> > then we don't install sha1pass which does things bad.

I looked into this. BusyBox cryptpw and mkpasswd are aliases for
essentially the same code, however mkpasswd has sane input (a
"Password:" prompt, and doesn't echo what you type to the terminal),
whereas cryptpw doesn't. Weird that cryptpw would work like that.

Anyway, those utilities use the crypt(3) call, which on uClibc can
generate DES and MD5 passwords. syslinux honors MD5. It also honors
SHA1, but I think not sha256 or sha512.

So we could omit installing the perl utility from syslinux, and just put
a comment in the config file describing how to generate an MD5 password
with mkpasswd, and that sha1 passwords are also honored. I guess it'd be
possible to generate the latter using openssl, but it'll require some
elbow grease and I haven't tested how to do it. (Whereas generating MD5
passwords in the right format using openssl is also straightforward.)

My understanding is that MD5 would be rather weak for blocking access to
one's hardware. But a meliorating factor is that an attacker who doesn't
yet have access to the hardware (or network access and root) won't be
able to see the MD5 hash. In any case, I propose to replace the use of
the sha1pass utility from syslinux with the instructions on how to
generate an MD5 password with mkpasswd.

While testing that, I discovered also that HDT is no longer working on
my machine. I did verify that I was using the latest version from
syslinux, and that this wasn't due to interaction with the password
protection, or any other obvious factors. I don't know what's wrong
there. But it used to work on my machine, and maybe it will work on
others' machines now, and hopefully it will work on my machine again in
the future. I don't think there's anything amiss with the menu entry
I've added to extlinux.conf enabling the use of HDT which is breaking
things here. For that reason, and also because the set of patches I've
proposed are inter-connected, maybe we should just push what I've
offered about HDT, and I'll start a background thread in my
mind/browsing to find out how to get HDT working again locally. Is that
tolerable?

-- 
Dubiousjim
[email-masked]

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Dubiousjim <[email-masked]>
Date: Sat, 29 Jun 2013 13:04:05 -0400

On Sat, Jun 29, 2013 at 11:49:05AM -0400, Dubiousjim wrote:
> and that sha1 passwords are also honored. I guess it'd be

For reference, this, using the perl utility from syslinux:

$ sha1pass pass salt
$4$salt$bZuH+MGRe/PzSo19kyjHeYHQT+k$

ought, so far as I have understood the relevant documentation, and the
code for perl-digest-sha1, be reproducible as follows:

$ printf '$4$%s$%s$\n' salt $(echo saltpass | openssl dgst -sha1 -binary | base64 | sed 's/=$//')
$4$salt$PKE3LoCWMo+QH2d2luTjhakNfFs$

However, as you can see the results are not the same. So there's
some piece here that I haven't yet understood.

-- 
Dubiousjim
[email-masked]

---

---

From: Timo Teras <[email-masked]>
Date: Sat, 29 Jun 2013 20:39:55 +0300

On Sat, 29 Jun 2013 13:04:05 -0400
Dubiousjim <[email-masked]> wrote:

> > possible to generate the latter using openssl, but it'll require
> > some elbow grease and I haven't tested how to do it. (Whereas
> > generating MD5 passwords in the right format using openssl is also
> > straightforward.)
> > 
> 
> $ printf '$4$%s$%s$\n' salt $(echo saltpass | openssl dgst -sha1
> -binary | base64 | sed 's/=$//') $4$salt$PKE3LoCWMo+QH2d2luTjhakNfFs$
> 

echo should have -n to inhibit the linefeed.

---

---

From: Dubiousjim <[email-masked]>
Date: Sat, 29 Jun 2013 15:48:56 -0400

> echo should have -n to inhibit the linefeed.

Exactly, that's it. How many times am I going to have to remind myself
to use printf instead of echo?

Thanks.

-- 
Dubiousjim
[email-masked]

---

---

From: Natanael Copa <[email-masked]>
Date: Sat, 29 Jun 2013 23:35:44 +0200

On Sat, 29 Jun 2013 11:49:05 -0400
Dubiousjim <[email-masked]> wrote:

> > >   main/syslinux: use more specific LINUX (instead of KERNEL) for
> > > kernels main/syslinux: reorganize menu layout
> > > main/syslinux/update-extlinux.conf |  9 +++++ 3 files changed, 66
> > > insertions(+), 20 deletions(-)
> > 
> > > 1) IMHO its useless use of perl. A tiny C app using crypt(3)
> > > would do the same job with less lines and without perl.
> > > 2) it requires that password is specified on command line. I
> > > think it should at least optionally be able to read it from stdin.
> > > 
> > > Could you please test if the cryptpw generated passwd works? If
> > > so, then we don't install sha1pass which does things bad.
> 

ah, i was not aware of mkpasswd. This is exactly what I was looking for.
> generate DES and MD5 passwords.

we patched uclibc for Alpine Linux to do sha512 by default.

> syslinux honors MD5. It also honors

after a quick look i got the impression of support for:

sha1:
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/com32/menu/passwd.c#n20

md5:
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/com32/menu/passwd.c#n50

sha256:
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/com32/menu/passwd.c#n59

sha512:
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/com32/menu/passwd.c#n68

> So we could omit installing the perl utility from syslinux, and just
> put a comment in the config file describing how to generate an MD5
> password with mkpasswd, and that sha1 passwords are also honored. 

I would have expected mkpasswd -m sha1 to work but it doesnt. (I'm not
too sad for that...) If syslinux supports $6$<salt>$<sha512hash> then
mkpasswd should 'just work'. If not, then i think could backport (or
add) sha512 support to syslinux.

> I guess it'd be possible to generate the latter using openssl, but
> it'll require some elbow grease and I haven't tested how to do it.
> (Whereas generating MD5 passwords in the right format using openssl
> is also straightforward.)

I bet its possible but I suspect its too complicated for deadly humans.
Lets stick to mkpasswd if possible.

> My understanding is that MD5 would be rather weak for blocking access
> to one's hardware. But a meliorating factor is that an attacker who
> doesn't yet have access to the hardware (or network access and root)
> won't be able to see the MD5 hash. In any case, I propose to replace
> the use of the sha1pass utility from syslinux with the instructions
> on how to generate an MD5 password with mkpasswd.

Yeah, I think MD5 would be 'good enough' for this usecase but its a
general good thing to avoid it nowdays.

> others' machines now, and hopefully it will work on my machine again
> in the future. I don't think there's anything amiss with the menu
> entry I've added to extlinux.conf enabling the use of HDT which is
> breaking things here. For that reason, and also because the set of
> patches I've proposed are inter-connected, maybe we should just push
> what I've offered about HDT, and I'll start a background thread in my
> mind/browsing to find out how to get HDT working again locally. Is
> that tolerable?

Yes, I'll push the patches (monday probably) as is, maybe with the
'mkpasswd' comment for 8/8 patch.

I have been thinking that there are many nice things in syslinux we
could use better but never had the time or energy to take a look at it.
I'm very happy for those patches :)

Thanks!

-nc

---

---

From: Dubiousjim <[email-masked]>
Date: Sat, 29 Jun 2013 19:03:55 -0400

> we patched uclibc for Alpine Linux to do sha512 by default.

Ah yes, I see: we configure uclibc's crypt to accept sha256 ($5$...) and
sha512 ($6$...). And it already does md5 ($1$...). But not sha1
($4$...).

> http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/com32/menu/passwd.c#n68

Good catch. Some of their online docs only list md5 and sha1, I think.

> add) sha512 support to syslinux.

Hmm, mkpasswd *seems* to work with --method=sha256 and --method=sha512.
At least, that's a reasonable guess about sha512. Whatever it outputs
for sha512 seems to be its default, and it will output the same for
--method=garbage.

I verified that python produces the same output.

$ mkpasswd --salt=salt --method=sha256 pass
$5$salt$BVuUtQaoLQNxrhdvvoTwUW5F0BihI9JdpEEgVrKrp6C
$ python -c "import crypt, getpass, pwd; print crypt.crypt('pass', '\$5\$salt\$')"
$5$salt$BVuUtQaoLQNxrhdvvoTwUW5F0BihI9JdpEEgVrKrp6C

$ mkpasswd --salt=salt --method=sha512 pass
$6$salt$3aEJgflnzWuw1O3tr0IYSmhUY0cZ7iBQeBP392T7RXjLP3TKKu3ddIapQaCpbD4p9ioeGaVIjOHaym7HvCuUm0
$ python -c "import crypt, getpass, pwd; print crypt.crypt('pass', '\$6\$salt\$')"
$6$salt$3aEJgflnzWuw1O3tr0IYSmhUY0cZ7iBQeBP392T7RXjLP3TKKu3ddIapQaCpbD4p9ioeGaVIjOHaym7HvCuUm0

Not sure how to duplicate that with openssl.

$ printf '$5$%s$%s\n' salt $(printf saltpass | openssl sha256 -binary | base64 | sed 's/=*$//')
$5$salt$nJW/kJzxe+qnpMcdhmcVZilGmamU23qqj/6gBPQllU8

is not the same result as above.

But I guess we can nevertheless rely on mkpasswd for md5, sha256, and
sha512. Haven't verified that this all works with syslinux, but I expect
it to.

-- 
Dubiousjim
[email-masked]

---

---

From: Dubiousjim <[email-masked]>
Date: Sat, 29 Jun 2013 19:27:16 -0400

> is not the same result as above.

Ah, the actual algorithm, available here:

http://www.akkadia.org/drepper/SHA-crypt.txt

means doing it by hand with openssl would be much harder than that.

-- 
Dubiousjim
[email-masked]

---

---

From: Natanael Copa <[email-masked]>
Date: Sun, 30 Jun 2013 13:23:37 +0200

On Sat, 29 Jun 2013 19:03:55 -0400
Dubiousjim <[email-masked]> wrote:
 
> sha512. Haven't verified that this all works with syslinux, but I
> expect it to.

Now we are on same page :)

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Sun, 30 Jun 2013 14:13:29 +0200

On Sat, 29 Jun 2013 11:49:05 -0400
Dubiousjim <[email-masked]> wrote:

> my machine.

copy libgpl.c32 and libmenu.c32 in addition to hdt.c32 to /boot.

(syslinux now uses elf format so you can use readelf or scanelf -n to
troubleshoot this kind of issues)

-nc

---