grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] luks2: Fix decoding of digests and salts with escaped chars


From: Patrick Steinhardt
Subject: Re: [PATCH] luks2: Fix decoding of digests and salts with escaped chars
Date: Sun, 3 Oct 2021 22:41:28 +0200

On Tue, Sep 28, 2021 at 12:55:24PM -0500, Glenn Washburn wrote:
> On Tue, 28 Sep 2021 17:13:10 +0200
> Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> > CC-ing Glenn...
> 
> Thanks, I missed this
> 
> > On Wed, Aug 11, 2021 at 08:55:32PM +0200, Patrick Steinhardt wrote:
> > > It was reported in the #grub IRC channel that decryption of LUKS2
> > 
> > Which IRC network?

On Libera.

> > > partitions fails with errors about invalid digests and/or salts. In
> > > all of these cases, what failed was decoding the Base64
> > > representation of these, where the encoded data contained invalid
> > > characters.
> > >
> > > As it turns out, the root cause is that json-c, which is used by
> > > cryptsetup to read and write the JSON header, will escape some
> > > characters by prepending a backslash when writing JSON strings. Most
> > > importantly, this also includes the forward slash, which is part of
> > > the
> > 
> > Wait, is not it jsmn lib bug? If it is should not we take updated
> > version of jsmn? Or if it is not fixed there propose jsmn upstream
> > patch?
> 
> I had this same thought. It looks like its not a bug in upstream, but
> expected behaviour and a known and intentional limitation[1]. Based on
> a cursory look, it seems that a goal of jsmn is to do no memory copying
> (I suppose to be aimed at memory constrained environments). So the
> parsed json strings returned are basically pointers into the original
> json string passed to the parser.
> 
> There has been some work to add unescaping[2], but nothing that has
> been accepted as far as I can tell.

Yeah, that's been my take as well here. It's surprising when you first
hit this, especially so given that the escaping is entirely optional.

> > > Base64 alphabet and which may optionally be escaped. Because GRUB
> > > doesn't know to unescape such characters, decoding this string will
> > > rightfully fail.
> > >
> > > Fix the issue by stripping the escape character for forward slashes.
> > > There is no need to do so for any other escaped character given that
> > > valid Base64 does not contain anything else.
> > >
> > > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > > Reported-by: Afdal
> > 
> > Reported-by should go before SOB. And it would be nice if you could
> > get Afdal's email address...

He didn't want to provide any, so I can either switch this and keep it
without mail, or drop the line entirely. As you wish.

[snip]
> > > +  grub_memmove (unescaped, in, inlen);
> > > +
> > > +  /*
> > > +   * JSON strings can escape some characters. Given that we expect
> > > +   * Base64-encoded input here, the only character from the Base64
> > > alphabet
> > > +   * which may optionally be escaped is the forward slash. We thus
> > > strip away
> > > +   * the escape character if we see '\/' in the input.
> 
> Not technically true[3], "Any character may be escaped". This is only
> true (I assume) when assuming that the current JSON lib that cryptsetup
> uses is used to create the json header.

Ah, fair. Thanks for the pointer.

> > > +   */
> > > +  for (i = j = 0; i < inlen; i++) {
> > > +    if (i + 1 < inlen && unescaped[i] == '\\' && unescaped[i + 1]
> > > == '/')
> > > +      continue;
> > > +    unescaped[j++] = unescaped[i];
> > > +  }
> 
> Another edge case would be to check for unicode escaped characters in
> the base64 alphabet. This would allow us to parse all valid base64
> encoded strings. Admittedly, it probably academic at this point because
> there's probably no LUKS2 software encoding, for instance, "A" as
> "\u0065". But I don't think it would be that hard to use a switch
> checking for "\u" followed by 4 digits in the proper range and decoding
> that.

Hum. We _can_ do this, but as you say it's rather academic. I'm on the
edge on how complete we want this to be. How about we just live with
this known shortcoming for now, but document that it only unescapes a
subset of JSON-encoded strings?

The other comments all look sensible to me, will apply. Thanks!

Patrick

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]