Package: firmware-b43-installer
Version: 1:018-2
Severity: important
Tags: security
X-Debbugs-Cc: drw...@2600nl.net, er...@debian.org, julien.voi...@dustri.org
Hi,
[Not sure about the severity. I suspect this could arguably be RC.]
firmware-b43-installer*.postinst download tarballs over plain-text
HTTP, and does not verify the downloaded files in any way. This means
that quite a few people can basically decide who gets which file:
* anyone controlling the system's DNS resolver (ISP, typically);
* anyone controlling DNS for www.lwfinger.com;
* anyone able to change the content served from www.lwfinger.com;
* basically any active network attacker on the path between the user
and www.lwfinger.com.
That's a lot of people, and I think that it's putting a great lot of
unwarranted faith into the Internet and its operators.
Then, the postinst scripts extracts the downloaded tarball, and runs
b43-fwcutter on a file it contains (respectively, wl_apsta.o and
wl_apsta-3.130.20.0.o). Let's hope that b43-fwcutter can safely be run
on untrusted data, because that's just what we're doing here. (By the
way, is there any reason why all this has to be done as root? But I'm
digressing, that should be for another bug report :)
Anyway, in the process, b43-fwcutter writes files to
/lib/firmware/b43*/. The following assumes that this part is done in
a safe way, and that overwriting arbitrary files elsewhere is not
possible. I've not checked if/how the destination filenames are
affected by the downloaded content. Maybe one of the Cc'd will want to
take a look.
Then, if some hardware supported by the b43* modules is plugged, some
of the extracted files will be loaded into a network device.
What could possibly go wrong?
1. It's one thing to trust Broadcom's firmware. It's a very different
thing to trust a not-so-small part of the Internet to provide
firmware to (possibly targeted) Debian users.
2. We're talking of remote arbitrary code execution here. Granted, the
code runs on a network device, instead of the main CPU. Still,
a whole lot of interesting things can be done this way.
3. The b43* kernel drivers might not be written with, in mind,
a thread model that includes "I'm talking to a device running
a firmware that can have been carefully crafted by an attacker".
It would be interesting to verify this. And/or to simply avoid
taking the risk.
I recommend that:
a) the source package stores the checksum of the files that are
downloaded in postinst (using e.g. the strongest hash that APT
supports, to make things consistent; or, better, store checksums
computed with *multiple* hash algorithms);
and
b) postinst carefully verifies that the downloaded files match the
expected checksums, and fails closed if that's not the case.
That's TOFU ("trust on first use"), but we can't do better apparently:
I've seen no cryptographic verification means proposed on
www.lwfinger.com. Adding TLS to the mix might be useful too, if only
it was available for that website.
Note that the postinst scripts must anyway be modified (to update
URLs) when a new release of the proprietary drivers is out, that we
want to use. So, it doesn't seem to add substantially more work on the
maintainers' shoulders to also update a file with checksums. It could
be automated relatively easily using some debian/rules make target.
Thanks for maintaining b43-fwcutter in Debian!
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
