Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #75589 > unrolled thread

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ben Hutchings <ben@decadent.org.uk> - 2022-06-13 18:30 +0200
    Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ben Hutchings <ben@decadent.org.uk> - 2022-06-18 16:30 +0200
      Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ben Hutchings <ben@decadent.org.uk> - 2022-06-18 16:40 +0200
      Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ben Hutchings <ben@decadent.org.uk> - 2022-06-19 13:10 +0200
        Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ansgar <ansgar@debian.org> - 2022-07-04 14:20 +0200
          Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ben Hutchings <ben@decadent.org.uk> - 2022-07-04 17:30 +0200
            Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service Ansgar <ansgar@debian.org> - 2022-07-04 22:10 +0200

#75589 — Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Multipart message — attachments visible in raw view] — view raw

Control: reassign -1 src:linux-signed-i386 5.10.120+1
Control: severity -1 serious
Control: tag -1 confirmed

On Mon, 13 Jun 2022 01:18:00 -0500 Daniel Lewart <lewart3@gmail.com> wrote:
> Package: linux-image-5.10.0-15-686-pae
> Version: 5.10.120-1
> Severity: normal
> 
> Debian Kernel Team,
> 
> Encountered on a physical machine and reproduced with QEMU:
> 
> $ sudo modprobe rt61pci
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> But it works fine on the following:
>   * linux-image-5.10.0-14-686-pae  Verson 5.10.113-1
>   * linux-image-5.10.0-15-amd64    Verson 5.10.120-1
> 
> Here is some more verbosity:
> 
> $ sudo modprobe -v rt61pci
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> $ sudo modprobe -vv crc-itu-t
> modprobe: INFO: ../libkmod/libkmod.c:365 kmod_set_log_fn() custom logging function 0x47b800 registered
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: INFO: ../libkmod/libkmod-module.c:892 kmod_module_insert_module() Failed to insert module '/lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko': Key was rejected by service
> modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
> modprobe: INFO: ../libkmod/libkmod.c:332 kmod_unref() context 0x204a2d0 released

I can confirm that this module does not load, and this means it has an
invalid signature.  The detached signature present in the source
package seems to be truncated (408 bytes long, where for all other
modules the detached signature is 411 bytes long).

The amd64 kernel package is also affected, but for a different module
(xt_l2tp).

Since the truncated signatures are in the source packages, this is a
problem introduced by the code signing service and will need to be
fixed there.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.

[toc] | [next] | [standalone]

#75660

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
[...]

> linux-image-4.19.0-17-amd64 4.19.194-1 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-2 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-3 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
[...]
> A significant pattern visible here is a short signature for the same
> module in multiple consecutive versions, where the module may have
> identical contents.  That implies that this is a reproducible issue for
> certain inputs that cannot be worked around by re-running the signing
> process.
>
> However, I have *not* yet verified that all short signatures really are
> invalid.

These module files are indeed identical, and their signatures are
rejected by the kernel.

I'm now looking at whether the missing bytes are recoverable (e.g. are
they always zeroes).

Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
or 0.0015%, so it's not surprising that other source packages have not
yet been affected.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

[toc] | [prev] | [next] | [standalone]

#75662

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
[...]
> Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
> or 0.0015%
[...]

Or maybe not so incidentally: 4,967,591 / 2^16 ~= 75

Ben.


-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

[toc] | [prev] | [next] | [standalone]

#75673

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
> On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
> [...]
> 
> > linux-image-4.19.0-17-amd64 4.19.194-1 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-2 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-3 lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> [...]
> > A significant pattern visible here is a short signature for the same
> > module in multiple consecutive versions, where the module may have
> > identical contents.  That implies that this is a reproducible issue for
> > certain inputs that cannot be worked around by re-running the signing
> > process.
> > 
> > However, I have *not* yet verified that all short signatures really are
> > invalid.
> 
> These module files are indeed identical, and their signatures are
> rejected by the kernel.
> 
> I'm now looking at whether the missing bytes are recoverable (e.g. are
> they always zeroes).
[...]

I wrote a script to try all possible byte values for 2 bytes before or
after the short signature.  For this particular file, none of them
producd a valid signature.  So the short signatures seem to be
corrupted in a more complex way.

In the mean time, we have another security update coming which might
not hit this bug again.  But there are 28,679 signed binaries across
the three architectures, so the probability is only about 65%.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
                                                 - Anne Morrow Lindberg

[toc] | [prev] | [next] | [standalone]

#75834

On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > they always zeroes).
> [...]
> 
> I wrote a script to try all possible byte values for 2 bytes before or
> after the short signature.  For this particular file, none of them
> producd a valid signature.  So the short signatures seem to be
> corrupted in a more complex way.

The "OCTET STRING" containing the actual signature is shorter for the
seemingly corrupted signatures:

+---
| $dumpasn1 ./linux-image-4.19.0-21-amd64-unsigned/lib/modules/4.19.0-21-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 404: SEQUENCE {
| [...]
| 151 254:           OCTET STRING
+---

vs

+---
| $ dumpasn1 ./linux-image-4.19.0-21-cloud-amd64-unsigned/lib/modules/4.19.0-21-cloud-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 407: SEQUENCE {
| [...]
| 151 256:           OCTET STRING
+---

Given the number of corrupted signatures is pretty much the number of
signatures where the two leading bytes should be 0 (as stated in [1]),
I suspect something (incorrectly?) outputs a shorter OCTET STRING
leaving out the 0 (as one might for a large integer type), but the
other side expects a fixed size?

If so, the file should validate if one injects two leading 0 bytes in
the OCTET STRING (and updates all length values). I would need to check
how to manipulate files using ASN.1's DER encoding to try this...

Ansgar

  [1]: https://bugs.debian.org/1012741#48

[toc] | [prev] | [next] | [standalone]

#75835

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2022-07-04 at 14:04 +0200, Ansgar wrote:
> On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > > they always zeroes).
> > [...]
> > 
> > I wrote a script to try all possible byte values for 2 bytes before or
> > after the short signature.  For this particular file, none of them
> > producd a valid signature.  So the short signatures seem to be
> > corrupted in a more complex way.
> 
> The "OCTET STRING" containing the actual signature is shorter for the
> seemingly corrupted signatures:
[...]

Yes I know, and my script uses a library to manipulate the ASN.1
structure when adding bytes.  I'm attaching the script, so you can
check the logic.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.

[toc] | [prev] | [next] | [standalone]

#75838

[Multipart message — attachments visible in raw view] — view raw

Hi,

I experimented a bit more and could reproduce the problem with a local
YK (Yubikey 4, Firmware 4.3.7) and a known private key and certificate.

The correct signature (using OpenSSL) has:

+---
| 138 256:           OCTET STRING
|        :             00 00 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6
+---[ data.ko.p7s.success ]

The incorrect signature from the YK has:

+---
| 138 254:           OCTET STRING
|        :             82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6 E7
+---[ data.ko.p7s.fail ]

So there is also a wrong byte at the beginning.
The incorrect signature also misses one byte at the end.

The attached archive contains:

 - data.ko: random data to be signed
 - data.ko.p7s.fail: incorrect signature generated by YK4
 - data.ko.p7s.success: correct signature generated by OpenSSL
 - reproduce.sh: sign with YK4 (set serial# in the first lines)
 - reproduce2.sh: sign with OpenSSL
 - sign-file: make this a symlink to linux' sign-file
 - test.key: private key
 - test.pem: self-signed certificate

The test.{key,pem} need to be loaded in the Digital Signature (Slot 9c)
slot of the PIV application.

I haven't checked if this is reproducible with another YK with the same
data/key/cert, but it is reproducible with the same key.

Ansgar

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web