Date: Tue, 05 Sep 2017 18:00:52 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 222077] geli(8) writing uninitialized memory out to disk Message-ID: <bug-222077-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222077 Bug ID: 222077 Summary: geli(8) writing uninitialized memory out to disk Product: Base System Version: 11.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: max@mxcrypt.com When geli(8) is configured to use authenticated encryption, it has to interleave data with HMACs. A 4096-byte encrypted sector requires nine 512-= byte sectors from the underlying provider, with the last sector having 224 bytes unused. I was configuring an encrypted vnode-type memory disk and decided to look at the metadata that geli writes to the end of the file with hexdump. To my surprise, I also found other plain-text data in the 224 unused bytes of eve= ry 9th sector. For example (hex columns omitted): 000ff520 |om>. <geom id| 000ff530 |=3D"XXXXXXXXXXXXXX| 000ff540 |XXXX">. <cl| 000ff550 |ass ref=3D"XXXXXXX| 000ff560 |XXXXXXXXXXX"/>. | 000ff570 | <name>diski| 000ff580 |d/XXXXXXXXXXXXX<| 000ff590 |/name>. <ra| 000ff5a0 |nk>3</rank>..<co| 000ff5b0 |nsumer id=3D"XXXXX| 000ff5c0 |XXXXXXXXXXXXX">.| 000ff5d0 |. <geom ref=3D"XX| 000ff5e0 |XXXXXXXXXXXXXXXX| 000ff5f0 |"/>.. <provider| 000ff600 |................| This is a portion of sysctl kern.geom.confxml (with real data replaced by X= s) that made its way into my memory disk file. The script below can be used to reproduce this problem, though the actual data will obviously vary. It may = be necessary to increase the memory disk size for this behavior to become apparent. It looks like geli is obtaining some uninitialized memory for the last outp= ut sector and not erasing the unused bytes before writing the sector out to di= sk. I took a brief look at the code, but couldn't figure out where the memory is coming from, so I'm not sure of the severity of this bug and whether it may expose some sensitive data. Either way, the uninitialized bytes should be either set to zero or replaced with random data to make them indistinguishable from the rest (though there= is probably no real security benefit from doing so because of the geli metadat= a at the end of the device). Script to create an authenticated memory disk (use `hd gelitest.md` to insp= ect contents): #!/bin/sh dd if=3D/dev/zero of=3Dgelitest.md bs=3D1M count=3D1 status=3Dnone md=3D$(mdconfig -f gelitest.md) || exit echo fakekey | geli init -a HMAC/SHA256 -B none -K - -P -s 4096 $md || exit echo fakekey | geli attach -k - -p $md || exit dd if=3D/dev/zero of=3D/dev/$md.eli bs=3D1M status=3Dnone geli detach /dev/$md.eli mdconfig -du $md --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222077-8>