[pkg-cryptsetup-devel] Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Guilhem Moulin]

On Sat, 11 Sep 2021 at 18:31:33 +0200, Christoph Anton Mitterer wrote:
> On Sat, 2021-09-11 at 18:06 +0200, Guilhem Moulin wrote:
>> Not wrong in my view, but incomplete and using undocumented escape
>> sequences yields unspecified behavior.
> 
> Well the problem is simply that anyone who uses in any of the fields
> e.g. \n will end up getting a true newline and not the literal \n, as
> one would assume from the documentation, which just mentions the octal
> escapes.

I was about to reply “like fsttab(5)” but it seems fstab-decode(8)
doesn't mangle ‘\xHH’, ‘\t’ or ‘\n’.  So either I misremembered testing
this at the time, or something changed meanwhile :-)  I'd argue that ‘\’
is a special character which per documentation “needs to be escaped
using octal sequences”, so both ‘\n’ and ‘\xHH’ yield unspecified
behavior, but I guess that can be made explicit.
 
> Btw, there might also be a subtle security issue:
> 
> If, for some reason, normal users are allowed to directly or indirectly
> control the contents of crypttab, they could probably inject shell code
> here:
>            eval "CRYPTTAB_OPTION_$OPTION"='${VALUE-yes}'

We assume that unprivileged users do not have write access to
/etc/crypttab (actually, $TABFILE), keyscripts, or initramfs hook/
scripts.  Otherwise one can replace askpass with `mail me at example.net`,
append ‘keyscript=gimme_your_password’ to crypttab entries, or simply
ship compromised executables in the initramfs image.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210911/c906b5b6/attachment.sig>