[HN Gopher] CVE-2023-40547 - avoid incorrectly trusting HTTP hea...
___________________________________________________________________
CVE-2023-40547 - avoid incorrectly trusting HTTP headers
Author : DyslexicAtheist
Score : 141 points
Date : 2024-01-25 17:49 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ImJamal wrote:
| Is this only a problem if you are doing some sort of network boot
| or do boot loaders connect to a network for another reason?
| nailer wrote:
| Network boot. If you have physical (or lights out) access to a
| box you can own it though.
| nightowl_games wrote:
| WOW
|
| It seems so obvious!
| mlhpdx wrote:
| Indeed. The header reads to me as "the server says this content
| length will be..." so I have always taken precautions with it.
| Servers can be wrong as well as malicious.
| rany_ wrote:
| But do these builds of shim include httpboot? AFAIK shim is just
| there to execute another EFI binary on the disk. I don't think
| I've ever seen the netboot functionality of shim get used.
| Arnavion wrote:
| shim is an EFI bootloader commonly used by Linux distros that
| want to enable Secure Boot. Distros want an easy path to enabling
| Secure Boot using the default preloaded Microsoft signing key,
| rather than require users to enroll their own key. But Microsoft
| refuses to sign GPL bootloaders like grub in general, so shim was
| made to be able to be signed by the Microsoft key. (shim then
| implements its own separate signature verification of what it
| boots, based on a different key called the Machine Owner Key,
| MOK.)
|
| When you tell shim what EFI binary to boot, you can specify it as
| an HTTP URL. If you do this and the HTTP server is malicious, it
| can trigger an out-of-bounds write.
|
| However, usually you use it to boot a local second-stage
| bootloader like grub (hence the name "shim"), so it's unlikely to
| be a problem for most installs.
|
| Regardless, Secure Boot was built from the start to allow
| previously-signed binaries to be revoked via the DBX list - a
| list of signatures that can be loaded into the UEFI to make it
| reject binaries even if they have a valid signature. When (If)
| the signatures of old shim binaries with this bug are added to
| the list, you can update the list in your own machines. Updates
| may be distributed as capsule updates (via LVFS etc), or if you
| manage your SB keys and vars you can download and enroll the list
| from https://uefi.org/revocationlistfile
| rany_ wrote:
| > because MS refuses to sign GPL bootloaders like grub in
| general
|
| This is because MSFT lawyers think that if you sign a GPLv3
| licensed bootloader like GRUB, you might have a right to compel
| the developer into handing over their signing keys.
|
| Source: https://techcommunity.microsoft.com/t5/hardware-dev-
| center/u...
| nailer wrote:
| > FYI the reason is that the GPL would require you to hand
| over the signing keys. If you sign a GPLv3 licensed
| bootloader like GRUB, you're forced to also make public the
| signing key... which defeats the purpose.
|
| That seems to be a ridiculous interpretation of the GPL (no
| personal offense meant, I'm sure you're a fine person but
| this idea is genuinely very silly).
|
| Signatures on binaries are not part of the source code, and
| therefore the GPL isn't concerned with them.
|
| Think of:
|
| - every signed binary for an open source app on a Linux
| distro or Windows install
|
| - Every open source web app delivered over a TLS cert
|
| Nobody has ever considered that the private keys used to sign
| the package, executable or web site cert to be required by
| the GPL.
| rany_ wrote:
| > Code submitted for UEFI signing must not be subject to
| GPLv3 or any license that purports to give someone the
| right to demand authorization keys to be able to install
| modified forms of the code on a device. Code that is
| subject to such a license that has already been signed
| might have that signature revoked. For example, GRUB 2 is
| licensed under GPLv3 and will not be signed.
|
| It does according to MSFT lawyers:
| https://techcommunity.microsoft.com/t5/hardware-dev-
| center/u...
| nailer wrote:
| > any license that purports to give someone the right to
| demand authorization keys to be able to install modified
| forms of the code on a device
|
| There's nowhere in the GPLv3 that says that (then again,
| that sentence doesn't imply there is). Anyone can
| download and modify the grub source code, and compile it.
| It doesn't mean Microsoft is obliged to sign their fork.
| I wonder if there's something that confused (or was bad
| faith interpreted) by Microsoft's lawyers?
|
| Maybe someone can just use another open source license?
| Ie, anything not called 'GPLv3' which, like every other
| OSS license, does not purport to give someone the right
| to demand authorization keys to be able to install
| modified forms of the code on a device.
| rany_ wrote:
| They're probably referring to this part of the GPLv3
| license:
|
| > "Installation Information" for a User Product means any
| methods, procedures, authorization keys, or other
| information required to install and execute modified
| versions of a covered work in that User Product from a
| modified version of its Corresponding Source. The
| information must suffice to ensure that the continued
| functioning of the modified object code is in no case
| prevented or interfered with solely because modification
| has been made.
|
| > If you convey an object code work under this section
| in, or with, or specifically for use in, a User Product,
| and the conveying occurs as part of a transaction in
| which the right of possession and use of the User Product
| is transferred to the recipient in perpetuity or for a
| fixed term (regardless of how the transaction is
| characterized), the Corresponding Source conveyed under
| this section must be accompanied by the Installation
| Information. But this requirement does not apply if
| neither you nor any third party retains the ability to
| install modified object code on the User Product (for
| example, the work has been installed in ROM).
|
| I believe the MSFT lawyers are right here, but obviously
| I'm not a lawyer.
| nailer wrote:
| Thanks! I was looking for the word 'sign' and couldn't
| find it.
|
| I now think I was wrong earlier.
|
| Summarizing https://www.gnu.org/licenses/gpl-3.0.html:
|
| > The information (ie 'methods, procedures, authorization
| keys, or other information required to install and
| execute modified versions of a covered work') must
| suffice to ensure that the continued functioning of the
| modified object code is in no case prevented or
| interfered with solely because modification has been
| made.
|
| The purpose of allowing signing is exactly to ensure
| modified code does not function in that environment.
|
| Yes MS (and you) would be right. GPLv2, BSD or MIT would
| be fine but GPLv3 would not.
|
| -----------------------------------
|
| Edit reply to baobun (rate limit means I can't post)
|
| I did think about that, but:
|
| > continued functioning of the modified object code
|
| is vague. Does it mean a new firmware binary should
| continue working _on the same device_ as the unmodified
| predecessor or using is a _new device_ (that allows
| arbitrary entities to sign) considered to be "continued
| functioning"?
| baobun wrote:
| Not exactly. AshamedCaptain gets it. If the device can be
| configured to trust a user-supplied key instead of or in
| addition to Microsoft's, there is no need to provide any
| keys. This is up to the hardware supplier.
|
| https://news.ycombinator.com/item?id=39134059
|
| https://news.ycombinator.com/item?id=39133999
| roblabla wrote:
| > There's nowhere in the GPLv3 that says that (then
| again, that sentence doesn't imply there is)
|
| It does, commonly called the anti-tivoization clause.
| Here's the text:
|
| > "Installation Information" for a User Product means any
| methods, procedures, authorization keys, or other
| information required to install and execute modified
| versions of a covered work in that User Product from a
| modified version of its Corresponding Source. The
| information must suffice to ensure that the continued
| functioning of the modified object code is in no case
| prevented or interfered with solely because modification
| has been made.
|
| > If you convey an object code work under this section
| in, or with, or specifically for use in, a User Product,
| and the conveying occurs as part of a transaction in
| which the right of possession and use of the User Product
| is transferred to the recipient in perpetuity or for a
| fixed term (regardless of how the transaction is
| characterized), the Corresponding Source conveyed under
| this section must be accompanied by the Installation
| Information. But this requirement does not apply if
| neither you nor any third party retains the ability to
| install modified object code on the User Product (for
| example, the work has been installed in ROM).
|
| > The requirement to provide Installation Information
| does not include a requirement to continue to provide
| support service, warranty, or updates for a work that has
| been modified or installed by the recipient, or for the
| User Product in which it has been modified or installed.
| Access to a network may be denied when the modification
| itself materially and adversely affects the operation of
| the network or violates the rules and protocols for
| communication across the network.
|
| > Corresponding Source conveyed, and Installation
| Information provided, in accord with this section must be
| in a format that is publicly documented (and with an
| implementation available to the public in source code
| form), and must require no special password or key for
| unpacking, reading or copying.
|
| From GPLv3, section 6. Conveying Non-Source Forms.
| nailer wrote:
| You're correct. See my response to the other poster.
| https://news.ycombinator.com/item?id=39133890
| cesarb wrote:
| > [...] any methods, procedures, authorization keys, or
| other information required to install and execute
| modified versions of a covered work [...]
|
| From what I understand, allowing the user to install
| their own trusted keys is enough; there's no need to
| allow users to sign with the "official" trusted key as
| long as that alternative exists.
|
| I suspect that Microsoft's worry is that they don't
| control the firmware (the motherboard manufacturers do),
| and some UEFI firmware might be broken and not allow
| installing alternative trusted keys. I believe shim
| solves this by adding an intermediate layer which also
| allows the user to manually install their own trusted
| keys, even if the firmware doesn't.
| snthd wrote:
| >are not part of the source code, and therefore the GPL
| isn't concerned with them.
|
| IIRC the GPL concerns itself with buildscripts etc. and
| GPLv3 was written with the tivoization of v2 in mind.
|
| https://www.gnu.org/licenses/quick-guide-gplv3.html
|
| >Protecting Your Right to Tinker
|
| >Tivoization is a dangerous attempt to curtail users'
| freedom: the right to modify your software will become
| meaningless if none of your computers let you do it. GPLv3
| stops tivoization by requiring the distributor to provide
| you with whatever information or data is necessary to
| install modified software on the device. This may be as
| simple as a set of instructions, or it may include special
| data such as cryptographic keys or information about how to
| bypass an integrity check in the hardware. It will depend
| on how the hardware was designed--but no matter what
| information you need, you must be able to get it.
|
| >This requirement is limited in scope. Distributors are
| still allowed to use cryptographic keys for any purpose,
| and they'll only be required to disclose a key if you need
| it to modify GPLed software on the device they gave you.
| ajross wrote:
| So... really no. The overall spirit of the GPLv3 text is
| that the license demands preservation of the ability of an
| end user to modify and run the software they receive, see
| all the discussion at the time it was being drafted about
| "TiVoization". It does not specifically speak to encryption
| and signatures being used by the loader environment, but
| it's absolutely reasonable to interpret it that way.
|
| If I buy a laptop from Lenovo, and it uses a signed GPLv3
| bootloader, and I want to modify and run a new version of
| that bootloader, I'm prevented by the lack of a signature.
| That action is exactly what the license demands Lenovo
| permit.
|
| Now, obviously this collides badly with the security
| requirements of the system. So it's likewise totally
| reasonable to imagine a court flipping the other way and
| refusing to literally enforce the GPLv3 because of the
| potential damage to the market. But if that happens, then
| what gives Lenovo any right to ship that GPLv3 software at
| all? Now they're subject to the bootloader authors
| demanding they stop shipment of the infringing product.
|
| No, the permissively-licensed shim compromise was the right
| choice.
| AshamedCaptain wrote:
| > No, the permissively-licensed shim compromise was the
| right choice.
|
| Why? Why on earth?
|
| IF Lenovo wanted to really ship a GPLv3 bootloader, all
| it imposes on Lenovo is they ship a method to install
| your own bootloader keys. Do you really disagree with
| that?
|
| Lenovo has already shipped hardware which requires
| magical incantations to install anything other than
| Windows (see Secured Core hardware). Why on earth anyone
| shipping FLOSS software would drop their pants to allow
| precisely this shitshow is over me.
| ajross wrote:
| I'm not the person you should be arguing with. I didn't
| write the license and I'm not the judge that would have
| to make the decision. I was explaining why the collision
| between software freedom and end user security
| requirements (which is a very real thing!) is seen as a
| risk to the people shipping and supporting actual
| hardware.
| AshamedCaptain wrote:
| There is no collision _whatsoever_ between software
| freedom and security requirements. It's an illusion which
| happens to be highly convenient to those who want to
| promote an artificially controlled market and sell that
| as snake-oil security.
| kmeisthax wrote:
| If this were true, it probably applies to both GPLv2 _and_
| v3, since they both require installation instructions.
|
| v3 adds an additional requirement that if you mere-aggregate
| GPL software and other software, and put the aggregate into a
| consumer product, you can't disable the other software
| because the GPL software was modified. I don't believe this
| would apply in the situation that these shims are intended
| for - i.e. installing an OS onto a desktop machine, as those
| are supposed to allow you to enroll new Secure Boot keys
| anyway.
|
| I also don't understand why a signature from Microsoft would
| actually trip _any_ of the above-mentioned requirements.
| Microsoft is not distributing the software, they 're just
| signing it - i.e. distributing a message saying "this shim
| with this hash can run". That's not a copyright violation, so
| the GPL doesn't come into play at all.
|
| Perhaps there's something else Microsoft does with their
| signatures that might trip GPL...
| rany_ wrote:
| To my knowledge, they aren't the ones signing the software.
| Microsoft runs a UEFI CA and just bless the developer's
| sub-CA. The developer is fully in control of their own CA
| and could sign whatever they want.
| AshamedCaptain wrote:
| No. I don't know if Microsoft "partners" have some
| special privilege, but for 3rd parties Microsoft will
| _never_ sign your CA. They sign individual binaries.
| bee_rider wrote:
| Maybe Microsoft just doesn't want to sign a GPL bootloader
| and so they had their lawyers come up with nebulous
| concerns as a fig leaf. Microsoft <3 Open Source after all,
| can't be seen as reluctant for business reasons.
| AshamedCaptain wrote:
| Note that under no circumstances can it "compel" you to hand
| over the signing keys. It can compel you to _stop
| infringing_, though. Which you may do by either stop
| redistributing GRUB , or by allowing your customers to
| install their own signatures, or if you are really stupid, by
| giving out your private keys. But you cannot be forced to do
| the later.
|
| As usual it's just FUD.
| gorkish wrote:
| I'm a strong advocate of open source who also happens to
| agree with microsoft's lawyers on this. Whether you believe
| this consequence of GPLv3 is intentional or unintentional, it
| is a consequence. The idea of somehow putting blame back on
| Microsoft for this is similarly twisted.
|
| Vendors shipping absolute shit implementation of SecureBoot
| that don't give the users authority over their own systems
| are the problem.
|
| Let's revisit this topic in the future to see how many
| systems actually get patched to revoke these signatures. My
| guess is that nearly 100% of shipping systems 1 year from now
| will still have these keys and still boot these vulnerable
| signed binaries right out of the box.
|
| One might hope that this issue thrusts the theater of Secure
| Boot into the public discourse, but like most other forms of
| irrelevant DRM, it will simply remain a hurdle that everyone
| has to keep jumping over until the end of time.
| SahAssar wrote:
| Wouldn't it be the same scenario as if I sign a release
| binary with a GPG key, or even sign a commit with GPL code
| with a GPG key?
|
| I don't get what is different between signing workflows
| that OSS has used for decades and this?
| AshamedCaptain wrote:
| The difference starts when the _right_ signature is
| required to continue using the software, preventing you
| from effectively modifying the software.
| taeric wrote:
| Couldn't they release a signature separate from the thing
| they signed? Leaving it as work that the open source
| world has to do to combine them into the derivative work?
| Surely an attestation/signature would be a fair use
| derivative work?
| AshamedCaptain wrote:
| > Vendors shipping absolute shit implementation of
| SecureBoot that don't give the users authority over their
| own systems are the problem.
|
| Microsoft itself has been the _first_ vendor who shipped
| systems where SecureBoot could neither be disabled nor the
| whitelist of signatures/keys replaced with your own. This
| would be _the only_ scenario where the GPLv3 would have
| anything to say ... if Microsoft were to be also shipping
| GRUB in that system, which they weren't .
|
| And such scenario is precisely one of those the GPLv3 was
| designed to impede. So it is most definitely intentional.
|
| There is no one to blame other than Microsoft.
| riedel wrote:
| I wonder if this is a consequence of the judicial system in
| the US. In Europe there is something called promesse de
| porte-fort (contract at the expense of third parties) as
| Microsoft is not party in the licence agreement I would say.
| Some effects of the GPL ( or rather interpretations) are just
| plain ineffective. I say this while not questioning the copy
| left in general.
| JohnFen wrote:
| > When you tell shim what EFI binary to boot, you can specify
| it as an HTTP URL.
|
| Thank you for explaining this. I was seriously curious as to
| why a boot loader would be doing any network communications at
| all.
| dharmab wrote:
| As a junior IT person long ago we used remote image booting
| in our lab to quickly test new software builds on real
| hardware. Back then it involved janky TFTP.
| fullspectrumdev wrote:
| The horrors of PXE? Where you end up with a clusterfuck of
| DHCP and TFTP to load the correct image?
| eurleif wrote:
| I'm curious how shim avoids the issue Microsoft is concerned
| about. Presumably if the anti-Tivoization clause of GPLv3 would
| require a Secure Boot signing key to be provided on request, it
| also requires a MOK signing key to be provided on request. The
| net result, then, seems to be that any arbitrary party can
| obtain signing keys which allow them to sign arbitrary code
| which will be booted (indirectly) via Secure Boot. How is that
| a meaningfully different outcome from the one we would have if
| Microsoft simply issued signing keys for GPLv3 projects like
| grub?
| Arnavion wrote:
| MS doesn't "issue" signing keys. MS _has_ a signing key that
| it uses to sign bootloaders, and which is the default key in
| every UEFI that wants to be able to boot Windows with Secure
| Boot enabled. (*)
|
| Their argument is that if they signed a particular distro's
| GPL-licensed binary, then the user of that binary can ask for
| the source to be able to regenerate that binary, and that
| would require the signing key for completeness to be able to
| boot that binary.
|
| shim is MIT-licensed so that requirement does not apply.
|
| (*) To be precise, the key used to sign Windows and the key
| used to sign the rest are different, but both are enabled by
| default. That said, in 2022 there was talk about some UEFIs
| disabling that latter key by default:
| https://news.ycombinator.com/item?id=32066919
| cesarb wrote:
| > I'm curious how shim avoids the issue Microsoft is
| concerned about.
|
| IIRC, shim has a way to allow someone physically present to
| add additional keys which will also by trusted by that
| instance of shim. That's enough to satisfy the GPL
| requirements.
| Arnavion wrote:
| Yes, that is how the MOK enrolment process works. The
| distro drops its MOK (the one it used to sign the kernel
| into the distro kernel package) into the ESP. On next boot
| shim notices the new key and asks the user if they want to
| enroll it. Similarly if the user wants to enroll additional
| keys for kernel modules they built themselves or got from
| somewhere else, they can do the same process.
| RcouF1uZ4gsC wrote:
| > When you tell shim what EFI binary to boot, you can specify
| it as an HTTP URL. If you do this and the HTTP server is
| malicious, it can trigger an out-of-bounds write.
|
| Can a malicious server just send a compromised binary directly?
| BillDemirkapi wrote:
| OP/bug finder here with some clarifying information. It's a
| common misconception that this issue can only be abused if you
| use HTTP boot. That is not the case at all, otherwise it
| wouldn't be Critical. This bug can be abused locally
| (privileged malware can overwrite the EFI partition), from an
| adjacent network if PXE boot is enabled (w/ MiTM), or remotely
| if HTTP boot is used (w/ MiTM).
|
| More details on these scenarios:
|
| 1. A remote attacker with no privileges in a man-in-the-middle
| (MitM) position could leverage the issue against a victim
| machine that uses HTTP boot. No direct access to the victim
| machine is required.
|
| 2. A remote attacker _with_ privileges and code execution on
| the victim machine could leverage the issue to bypass Secure
| Boot, _even if the victim does not already use HTTP boot_ (as
| long as firmware has HTTP support). How? Several ways:
| - An attacker can edit the boot order variable to specify a
| controlled attacker server. - An attacker can
| chain shim->GRUB2->shim (via HTTP). For this technique, an
| attacker would overwrite the boot loader in the EFI partition
| to a legitimate shim and GRUB2 image. The attacker would create
| a grub.cfg that chainloads a new shim via HTTP. This is
| possible because GRUB2's device syntax allows you to specify
| any supported device, including HTTP (if available).
|
| 3. An adjacent attacker with no privileges in a man-in-the-
| middle (MitM) position could leverage the issue against a
| victim machine that uses PXE boot. PXE is separate from HTTP
| boot, but similar to the local vector, an attacker can chain
| together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).
| Arnavion wrote:
| Yes, if the attacker can edit the the victim machine's EFI
| vars or the contents of its ESP, then they can make the
| victim machine use HTTP boot even if the victim machine
| didn't use HTTP boot originally. However at that point they
| can also wreak more havoc without involving HTTP boot.
|
| For the case where the default configuration has been set up
| to just chainload grub (ie what distros use shim for), and
| where an attacker editing EFI vars / ESP is not in the threat
| model, there is no concern. Yes that is just "It's not a
| concern because you defined it to not be." but that is the
| reality for most users of Secure Boot on Linux.
|
| Also note that the reason I wrote that paragraph is because
| the HN submission was originally submitted with a title along
| the lines of "Every install of shim is affected".
| lmm wrote:
| > Yes, if the attacker can edit the the victim machine's
| EFI vars or the contents of its ESP, then they can make the
| victim machine use HTTP boot even if the victim machine
| didn't use HTTP boot originally. However at that point they
| can also wreak more havoc without involving HTTP boot.
|
| How? The whole point of secure boot is that an attacker
| with even that level of access can't boot the machine in an
| authenticated way (and e.g. make the disk encryption key
| available).
| Arnavion wrote:
| >How?
|
| Someone with enough privileged access to write to the ESP
| (ie root) can also add their own MOK to the ESP that the
| user might blindly accept next time they boot. Especially
| if they time it for when there is a legitimate new MOK in
| the ESP waiting to be accepted on next boot, so that the
| user is predisposed to accepting a new key.
|
| They can also replace shim with other binaries with other
| vulnerabilities that were signed by the MS key in the
| past, in case DBX hasn't been updated with their hashes.
|
| >The whole point of secure boot is that an attacker with
| even that level of access can't boot the machine in an
| authenticated way (and e.g. make the disk encryption key
| available).
|
| Someone with enough privileged access to write to the ESP
| (ie root) can also just exfiltrate your disk contents at
| that point.
| lmm wrote:
| > Someone with enough privileged access to write to the
| ESP (ie root) can also add their own MOK to the ESP that
| the user might blindly accept next time they boot.
| Especially if they time it for when there is a legitimate
| new MOK in the ESP waiting to be accepted on next boot,
| so that the user is predisposed to accepting a new key.
|
| > They can also replace shim with other binaries with
| other vulnerabilities that were signed by the MS key in
| the past, in case DBX hasn't been updated with their
| hashes.
|
| Neither of those sounds like a sure thing. The first
| relies on the user not checking the key, and is exposing
| the attacker to a lot of risk if they do. The second
| relies on DBX not being updated, for which the remedy is
| "don't do that".
|
| > Someone with enough privileged access to write to the
| ESP (ie root) can also just exfiltrate your disk contents
| at that point.
|
| The idea is that your main data partition is encrypted
| with a key held in a secure enclave and can only be
| retrieved after a secure boot. (Or, y'know, any of the
| other things people would use secure boot for). Your boot
| partition has to be unencrypted so you can boot from it,
| but there's no sensitive data on there, and an attacker
| with write access can't "rootkit" it because if they
| replace the bootloader with a different one then it will
| be unsigned and break the chain of trust. Again if this
| stuff didn't work then there would be no point in secure
| boot at all.
| 1970-01-01 wrote:
| The S in HTTP is to be used when important things are happening.
| This includes booting your device. HTTPS headers have always been
| encrypted. Still a good catch.
| oconnore wrote:
| HTTPS is irrelevant here. You can send incorrect headers in
| either.
| 1970-01-01 wrote:
| MITM scenarios say it isn't :P
| skottenborg wrote:
| I'm not sure HTTPS is an option for this as it requires
| accurate time/date for encryption. Maybe the RTC could be
| valid, but I'm not sure it handles different time zones well
| and it might have lost time anyways.
| 1970-01-01 wrote:
| I would classify something that doesn't care what century
| it's booting into as an unimportant device. If the clock is
| off by a lot, it still should not boot over network.
| Arnavion wrote:
| HTTP support is implemented by an EFI driver, so it's up to
| the UEFI to provide it in a way that works. The UEFI spec
| allows both HTTP and HTTPS URLs.
| halayli wrote:
| it has nothing to do with whether the S is present or not. Not
| sure you understood the problem.
| stonogo wrote:
| I have to say this is definitely a bug and I'm glad it's fixed
| ... but what kind of psycho boots their machine from an untrusted
| host? If the attacker controls the http service tightly enough to
| send malicious headers, avoiding this overflow is the least of
| your problems, since they have compromised your certs and also
| can just send a compliant payload with more malware on it.
|
| Bug? absolutely. Critical? not so sure.
| hackernudes wrote:
| Perhaps it could be used to break in to some locked devices.
| TheSoftwareGuy wrote:
| The only good form of defense, is defense in depth, or forming
| layers of defense. This bug puts a hole in one of those layers
| AshamedCaptain wrote:
| The same kinds of psycho who promote Secure Boot. They _really_
| believe in a security strategy which _requires_ everything that
| could be potentially be compromised to not be signed by Secure
| Boot. The moment you have something signed which has a
| vulnerability, you can use it to decrypt everyone's
| SecureBoot+TPM encrypted hard drives.
|
| Why that ever was considered a valid security approach is over
| me, as there is an entire gallery of vulnerabilities like this
| one. It also completely ignores the elephant in the room called
| Windows.
|
| Example of this type of thinking:
| https://lkml.org/lkml/2018/4/3/767
|
| Note that despite Linus' reticences, in a lot of distros
| integrity mode is indeed enabled when you boot with Secure Boot
| on. Likely because of MS politics and distros wanting an MS
| UEFI signature being forced to "go through the hoops" as
| explained in that thread. As a result enabling Secure Boot
| usually cripples your distro, preventing you from e.g.
| hibernating.
| pizzalife wrote:
| > Content-Lenght
| hypeatei wrote:
| Very embarrassing and unacceptable. /s
| jiripospisil wrote:
| > Critical bug that exists in every Linux boot loader signed in
| the past decade
|
| Huh? This is a bug in a single bootloader. It has nothing to do
| with other bootloaders. And while on the subject, consider
| whether you actually need a bootloader at all.
| ixtli wrote:
| Also worth noting the commit which introduced this was made 8
| years ago so not quite a decade.
| merb wrote:
| uf. I think a lot of frameworks had these issues. but nowadays
| its either rejection of the request or handlded like chunked
| encoding
| silisili wrote:
| Maybe I'm not well versed enough, but I thought most http clients
| read at most content-length specified, and consider it an error
| if read bytes < content-length.
| Arnavion wrote:
| The HTTP client is provided as an EFI driver by the UEFI.
| AFAICT the UEFI spec doesn't specifically say what the behavior
| should be if the content-length header doesn't match the
| response body length, so it might very well be possible that
| some implementations just make `connection:close` requests and
| don't check the content length.
|
| The vulnerability was reported by MSRC and none of the text
| about the CVE mentions an actual exploit. It might be revealed
| later, or it might just be theoretical.
| Arch-TK wrote:
| For anyone wondering "Why would you boot from an
| untrusted/compromised server?" or "Isn't this moot? If the server
| is compromised, it can just send a malicious binary." the short
| answer is:
|
| The binary that the shim ends up booting has to be signed by the
| MOK. So it should continue to provide the same security
| guarantees whether you're booting from within a compromised
| network, over HTTP, or if you're booting from a compromised
| server (even if it's over HTTPS).
|
| It's also important to note that secure boot doesn't prevent
| downgrades, so the fact that a compromised server could be
| utilised in a downgrade attack is not relevant. You would need to
| implement downgrade attack prevention in a more robust way
| regardless.
|
| That being said, I don't know _why_ the shim needs to support
| http boot (after all, nothing stops this from being implemented
| as second local EFI binary which handles it and is signed by the
| MOK), aside from maybe that it was thought to be a relatively
| simple feature to implement.
| barbazoo wrote:
| Can someone explain to me please why reading _less_ than the
| actual length of the body is dangerous? I'd have expected the
| opposite to be case.
| dwattttt wrote:
| From the description, it allocates a buffer based on Content-
| Length, but copies the size of the buffer it received, thus
| writing out of bounds of the allocation.
| lcnPylGDnU4H9OF wrote:
| > When retrieving files via HTTP or related protocols, shim
| attempts to allocate a buffer to store the received data.
| Unfortunately, this means getting the size from an HTTP header,
| which can be manipulated to specify a size that's smaller than
| the received data. In this case, the code accidentally uses the
| header for the allocation but the protocol metadata to copy it
| from the rx buffer, resulting in an out-of-bounds write.
| pwdisswordfishc wrote:
| Except that Content-length is not the length of the actual body,
| it is the length after Content-encoding...
___________________________________________________________________
(page generated 2024-01-25 23:00 UTC)