> Final update: A couple of days before the embargo ended (and after I wrote the majority of this blog post), AMD told me what their patch for this vulnerability is [...] Although it is true that they now fully use HTTPS, the claim about signature verification is untrue; they only perform a CRC-32 check on the downloaded executable, which is not cryptographically secure.
So solves the MITM, but massive infection is still trivial if someone compromises the webserver.
SahAssar 21 hours ago [-]
> someone compromises the webserver
Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?
Terr_ 20 hours ago [-]
What? The bootstrapping happened already! The official and correct AMD software already running on the computers. Preventing a human from falling for an impostor-website with malicious Download Now links is a separate problem.
The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private key. You don't need to do fancy things like global certs, discoverable keys, or revocation lists.
If today's installation doesn't have those checks and relies solely on HTTPS... well, that's unfortunate, but it's not like it poses a tricky dilemma! You simply use today's not-so-secure mechanism to install the new code which has more-secure behavior, and it closes the attacker's window of (easier) opportunity.
SahAssar 20 hours ago [-]
> The current installation shall already contain one (or more) public keys that it trusts for updates
The current installation was fetched via HTTPS, right? Either by you or in the factory.
Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere
Terr_ 19 hours ago [-]
I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are:
A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised.
B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com .
C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy.
Those are all interesting to contemplate, but they are at best "out of scope".
Terr_ 18 hours ago [-]
[Followup] To over-communicate in the hope that it somehow resolves things, we already have this chain of trust:
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.
lazide 19 hours ago [-]
Sure, but the OEM is the definition of a ‘trusted environment’. They literally are assembling the equipment, if you can’t trust that, nothing else can be trusted from that point on anyway.
19 hours ago [-]
19 hours ago [-]
rwmj 20 hours ago [-]
AMD (and Intel and everyone else) processors already have an HSM inside for confidential computing so use that? I would hope the HSM isn't as badly implemented as this update mechanism, but then again ...
bri3d 20 hours ago [-]
AMD Software Engineers giving AMD Stupid Gaming Accessory Software Engineers access to a signing system backed by PSP seems like a much worse outcome than trusting HTTPS, really. Like, there are definitely intelligent and secure ways to do this, but this one in particular is overkill with a huge blast radius when it is (invariably) done incorrectly.
SahAssar 20 hours ago [-]
Those have been broken again and again. Even if not, how do you distribute the public keys for it, how do you bootstrap that trust?
rwmj 19 hours ago [-]
Confidential computing is a whole thing with a key in each processor and a chain of trust and a way to remotely attest that your software is running in a secure enclave. All the vendors do it differently (sadly) but it's very much a solved problem.
bravetraveler 20 hours ago [-]
There was a time when RDRAND on Zen gave all zeroes, or something, so eh...
I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now. Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence.
As things stand, I'm not sure key rotation would go well... the updater doesn't mind itself, apparently.
stinkbeetle 15 hours ago [-]
I prefer 7 myself, but 0 is a perfectly good random number.
bravetraveler 15 hours ago [-]
Ah, well, they disagreed and patched it. Now we get no say.
Avamander 7 hours ago [-]
Wacom does the same CRC-32 BS in their updater.
I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.
pseudohadamard 11 hours ago [-]
It's OK though, AMD is a US company so there's nothing to worry about. It's only when a Chinese company does the same thing that it's an evil CCP backdoor designed to destroy civilization.
notepad0x90 22 hours ago [-]
what are the chances of them caring so little, but implementing a dedicated signing server, HSM,etc..? even if they sign it, it will probably be done on the same web server.
DANmode 20 hours ago [-]
> someone
LearnYouALisp 19 hours ago [-]
"Things break, Colonel!"
tlb 1 days ago [-]
It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.
tptacek 22 hours ago [-]
It's not out of scope "for taking over your computer". It's out of scope for the specific goals of the bug bounty program. Bug bounties are (usually) about prioritizing internal engineering effort; they are to vulnerability remediation what market feedback is to feature/function decisions in the rest of the product.
Everyone's judging this by the standard of "how good a bug" this is. But that's not necessarily how a bug bounty should function. Important prior to frame this with: neither any individual bug bounty submission nor the sum of all valid submissions materially alters the security of a serious product, at least not on their own. The system they feed into (for instance: security engineers taking a validated bounty submission and then quickly auditing the entire tree for variants of the same bug) can move the dials. The bounty bugs themselves though are mostly a sideshow.
What's especially weird (you didn't say this, but the sentiment has popped up on all 3 threads about this story) is the idea that AMD would be trying to cover this up. Why would they care? They run a bug bounty program. They've accepted the premise that they have vulnerabilities.
But it should be their job to protect against MitM in their threat model. There is no rational reason to exclude them from the bug bounty. Doing so only leaves MitM attacks like this undisclosed.
tptacek 19 hours ago [-]
I just gave a rational reason to exclude them from the bug bounty, which I can summarize as "the bug bounty is not their entire security program and does not have the goal you've axiomatically derived for it".
Cards on the table I am not a fan of bug bounty programs, and the fact that they're an engineering process that turns out to be impossible to have public engineering discussions about is definitely one of many reasons why. Most companies should not run bug bounty programs.
amiga386 1 days ago [-]
MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope.
MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.
pietervdvn 1 days ago [-]
I'd even count this as "having local access to the device", as that is what is needed to install such a cert
arcfour 1 days ago [-]
I think it's fair to say that requiring local administrative access to the device is out of scope, since you have already completely pwned the device in that case, which is what what you need to install a CA cert on any OSes.
inlined 19 hours ago [-]
In honor of The Old New Thing I call these “Vogon vulnerabilities”: I have a marvelous exploit in mind that pwns anyone I have root access to
josephg 15 hours ago [-]
The list of preinstalled CAs is long. I think its a safe bet that many nation-states have covert control over at least one CA on that list. (Or they have one of the root signing certs). HTTPS is way better than HTTP. But I'd personally rather if these random organisations didn't have RCE on my computers.
I've never heard of most of them. AAA Certificate Services? AC RAIZ FNMT-RCM? ACCVRAIZ1? Actalis? AffirmTrust? Even Godaddy is in there. I know I don't trust those guys.
Trust has gotta start somewhere. But its much better to TOFU, then pin signing keys in the updater.
joxdosba 1 days ago [-]
Why would anyone ever exclude true mitm?
Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned.
The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want.
Although I suppose the aforementioned problem has significant implications beyond dns…
gruez 1 days ago [-]
>Why would anyone ever exclude true mitm?
Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.
joxdosba 13 hours ago [-]
Sure, but this is more akin to dismissing a 1click RCE as “social engineering” because an employee has to be convinced to click a link.
zulln 23 hours ago [-]
Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.
tptacek 21 hours ago [-]
No, excluding SE is to make sure the bounty program is incentivizing things that inform the product security team. Social engineering is a corpsec function; they're not even the same teams.
sigmoid10 1 days ago [-]
Out of scope does not necessarily mean out of impact. It is merely a question of how far a company wants to be responsible for the environment their software is run in. Most of the time that answer is "not much."
tuckerpo 1 days ago [-]
Out of scope in this case means "we don't wanna pay you"
cogman10 24 hours ago [-]
Apparently it also means "We don't want to pay our engineers to fix this".
dlcarrier 1 days ago [-]
But I use a Wi-Fi password, so my phone says it's secure!
nickdothutton 1 days ago [-]
AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.
RachelF 23 hours ago [-]
Yes, their software is terrible across CPUs and GPUs, and continues to be. So many trivial bugs just never fixed.
It has literally cost them a Trillion dollars in market cap - Nvidia's CUDA is a big reason they're so much bigger than AMD.
voakbasda 21 hours ago [-]
And that’s saying something, because the CUDA stack is a PITA.
cute_boi 21 hours ago [-]
AMD somehow got success, but their company culture and pay is shit. They expect PHD level experience but expect pay like peanuts....
ethbr1 20 hours ago [-]
> expect PHD level experience but expect pay like peanuts
Thought this was par for the course in closer-to-hardware engineering.
Never understood why the objectively way harder jobs pay so much worse as an industry.
greenavocado 4 hours ago [-]
Academic overproduction?
Bilal_io 23 hours ago [-]
Their pay is shit. I interviewed with them 3 years ago and they offered me peanuts I rejected their offer.
tgsovlerkhgsel 11 hours ago [-]
This is a pretty common behavior that I've seen from bug bounty programs:
> a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms.
Companies reject bugs as out of scope and/or sit on them forever, then use the bug bounty ToS as intimidation to keep people from disclosing them. And sadly, it works.
I'm adding AMD to my list of companies that prefer their bug reports to be a public full disclosure rather than attempting to go through their bug bounty program.
dcminter 1 days ago [-]
The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
jeroenhd 1 days ago [-]
It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
10000truths 23 hours ago [-]
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
LgWoodenBadger 1 days ago [-]
A manager somewhere made the embarrassingly wrong decision to not fix this, and they’re too egotistical to correct their mistake.
That’s my take.
throwway120385 1 days ago [-]
Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.
wat10000 1 days ago [-]
More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.
AlotOfReading 1 days ago [-]
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
brokenmachine 18 hours ago [-]
It's trivially easy to create a malicious file with the same CRC as another file.
So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.
AlotOfReading 16 hours ago [-]
The entire point of my post was that it's trivial, exactly as difficult as computing the CRC in the first place. Not sure why that was controversial.
Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.
brokenmachine 12 hours ago [-]
It's fairly trivial, but still significantly harder than computing a single CRC.
From stackoverflow:
Because a 32-bit CRC yields only 2³² (approx. 4.29 billion) possible outputs, the Birthday Paradox dictates a 50% chance of an accidental collision after processing just ~77,000 unique inputs.
I've done it for shits and giggles and from memory it took my desktop PC maybe 10 minutes to generate a collision.
You're missing the point though.
Noise is not the only thing they should be protecting against.
The point is that AMD is executing code based on checking using an algorithm that has barely any protection from malicious inputs, which is stupid, and not fixing it just compounds that stupidity.
A cryptographic signature protects against both noise and malicious inputs.
AlotOfReading 11 hours ago [-]
It's fairly trivial, but still significantly harder than computing a single CRC.
You can do it with a single GF(2) multiplication, ignoring the complications of reflection and such. A normal CRC is just the special case of making the remainder 0 (again ignoring complications). You can also brute force it, but that's a bit slow for 64 bit CRCs and well, nanoseconds vs minutes in your example.
Noise is not the only thing they should be protecting against.
Sorry, can you point to the comment where I tried to defend AMD's use of CRCs in this particular application? I think I've made it pretty clear that I don't think they're appropriate for cryptographic applications. I was just talking about the math.
Different tools for different purposes. You probably don't want to be using your mac scheme for noise resistance, because then you're paying a cost in either buffer space, PDU size, or retransmits, and your error correction capabilities are nil. CRCs allow some error correction (albeit rarely used and inefficient for multibit errors vs FECs), good bit error detection properties, and are cheap. It's common to use both at different layers of a protocol stack.
22 hours ago [-]
sitkack 1 days ago [-]
They should have done base64 encryption before the crc32. noobs
tptacek 1 days ago [-]
AMD didn't deny it was a vulnerability; they denied it was in the scope of the bounty program.
Remember that at giant tech companies, the incentive is to pay out bounties --- there are people on the vendor's team whose performance is measured in part by how much the program pays out.
odyssey7 1 days ago [-]
What hair is this splitting? The issue was that AMD allowed a known and serious security vulnerability to exist within their customers’ systems, for months, and acted with a lack of candor while doing so.
tptacek 1 days ago [-]
It's not hair-splitting; it's central to the idea of a bug bounty. Too many people have weird ideas about what bug bounties are for.
odyssey7 20 hours ago [-]
Okay, fair. I was thinking mostly about the high-impact issue of preserving the security vulnerability and how an essential vendor was not being candid, but you are also right to note how AMD was avoiding its responsibilities to the individual researcher himself.
tptacek 20 hours ago [-]
I mean I think you think you're doing bank-shot snark here, but what you're really revealing is that your premises hinge on AMD trying to get out of paying a bounty simply to avoid paying it. Since we know up front that's not one of AMD's incentives, what does that do to your argument? It can't help.
Hizonner 1 days ago [-]
Yeah, like the weird idea that those programs are intended to in some way reduce the number of exploitable bugs actually out there.
tptacek 1 days ago [-]
That's in fact often not their core purpose!
JumpCrisscross 1 days ago [-]
What is it?
tptacek 1 days ago [-]
(First, I'm sorry I was so terse upthread; I had to get up early for a meeting and was scrolling HN in bed while it was happening without my reading glasses on; I should learn to stop commenting when I'm like that.)
I've written about this before here, but to sum it up:
* Unless something wild happens in software engineering (formal methods, &c) as a result of AI, there's no such thing as eradicating security vulnerabilities. Focused programs can eliminate low-hanging fruit, but at the point where you're offering significant bounties part of the premise is that all that fruit has been plucked. The marginal security impact of a single bounty award, by itself, is immaterial.
* What bounty programs can do is focus internal engineering attention. Large product teams have huge backlogs of issues and security design punch lists. For features and feature bugs, there's a closed loop that prioritizes the work: the market. For security vulnerabilities, bounties serve a similar purpose. This is why many bounties are tightly scoped; the whole point of the program is to direct the efforts of specific product teams.
* When we're talking about 10,000+ person engineering teams, the most important thing to know about bug bounty programs is that the company is incentivized to pay out. No major tech company that runs a bounty is "covering up" vulnerabilities. There's no reason for them to do so. They're running a program that ostentatiously pays rewards to people who report vulnerabilities! There are people on the teams managing the bounties who in effect get paid more when the program pays out more: that's what success looks like.
You add all this stuff up and all the drama about AMD (or Google or whoever) being shady or stingy basically never add up.
stickfigure 14 hours ago [-]
Then the guy should have let the public know about it 124 days ago. If AMD doesn't care, the discoverer shouldn't either.
tptacek 13 hours ago [-]
Absolutely.
Hizonner 1 days ago [-]
... which is why the rest of us should give them, and those who operate them, zero respect.
Nobody but AMD gives a fuck about AMD's internal policies or motivations.
tptacek 1 days ago [-]
I have thought about AMD's security team and their practices once in the past 18 months, and it was this morning, reading this thread. I do not care about AMD or what you think about AMD. AMD has absolutely nothing to do with my point.
Hizonner 23 hours ago [-]
You commented on this very issue when it first came up 4 months ago. If I remembered that, so should you. I mean, I'm prepared to believe that you did not think on that occasion, if you want to confirm that's what you mean...
If you don't care about AMD, why are you white-knighting AMD and defending AMD's bad behavior?
But, hey, OK, let's not make it about AMD specifically. It doesn't matter what any company thinks the purpose of its program is, nor does it matter what scope any company unilaterally decides to set for its program. What the outside world is going to see is whether or not you ignore security bugs. Your weird arcane internal policies, justifcations, and "scopes" are irrelevant. And, although I don't honestly care much about "security researchers", you can't really expect them to keep track of your private set of scope rules either... assuming you even tried to tell them the rules in advance to begin with.
tptacek 22 hours ago [-]
Why do you think we're going to have a productive conversation after accusing me of "white-knighting" for AMD (and how does that even make sense? What's your mental model of why I would be doing that?)
My motivation here is very simple: I think people dunking on AMD's bounty program here mostly don't understand how bug bounties function. You apparently keep track of my comments on HN, so I think you know that's a beat I have here.
gusgus01 17 hours ago [-]
How do we know the incentive is to pay out bounties? And how do we know that doesn't change on the whims of the management chain?
We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs and reduction of overhead initiatives thinking that the solution is to convince everyone you do payouts, but actually minimize payouts, which you could do by creatively using scopes.
tptacek 17 hours ago [-]
You're right. AMD could for some reason be unlike every other major tech company that runs a bug bounty. Maybe AMD stood up a public bounty where people get their pay docked when bounties get paid, rather than perfed up. They would potentially save, say, 0.000289% of their annual revenue, in exchange for stories like these. Checks out.
gusgus01 14 hours ago [-]
I'm not claiming to know how any major tech company runs their bug bounty program. I'm actually trying to claim that we can't know how AMD (or any of them) do, we can merely express our opinions on it. We can discuss all the public incentives they may have (and our interpretations on how those incentives should play out), but we don't see the internal bureaucratic incentives or the personal incentives or etc etc etc.
We also regularly see how the incentives we see as outsiders (and somewhat insiders) are regularly perverted. For the VW emissions scandal someone could have argued that the incentives were plain and clear, "Design better engines", but they instead went with "Design better ways to scam the tests". This is on top of the way companies will mask their true incentives, like how renewable energy programs are sometimes actually just the smart financial decision but it'll be portrayed as part of the green movement.
To include some explicit personal opinion, I can't throw a stone without hitting a news story about a company that thought they could get away with something but then eventually got called out by it... and they ultimately still got away with it.
tptacek 14 hours ago [-]
This is not the VW emissions scandal.
gusgus01 14 hours ago [-]
I'm aware that AMD was not involved in the VW scandal, and that that's not what TFA is about. Was that not clear?
It was a pop culture example of incentives gone wrong to hopefully support why incentives aren't clear cut.
sakkura 1 days ago [-]
They wanted to keep it quiet. As if they did not mind if it was exploited by those with access to international network links.
> In my frustration, I decided to punish this software
Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.
hilariously 1 days ago [-]
I got so mad at plex/jellyfin's crap I vibe coded an entire entertainment system out of spite.
Works great!
OkayPhysicist 1 days ago [-]
AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share.
For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.
20k 23 hours ago [-]
AMD's entire software development strategy is insane. OpenCL was doing reasonably well, and then AMD have just fully dropped support for some reason. For the - albeit not huge - but actual cross platform API that people were using to develop for their GPUs. For a while, a few cross platform tools had OpenCL backends, but nobody has been able to get AMD to fix any of the damn bugs. In my testing, bug latency for even the most trivial but important bugfixes is often 4+ years, which is utterly mad. Some parts of their compute stack is so broken its clear that nobody has ever used it. There are exploitable privilege escalation vulnerabilities caused by threaded race conditions that are wontfix
They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most
Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?
Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money
As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point
z3ratul163071 23 hours ago [-]
likewise. i'm bewildered throughout the years.
my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
actionfromafar 23 hours ago [-]
The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.
Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)
But despite that, I also believe AMD would be better off just implementing CUDA.
rincebrain 20 hours ago [-]
They did, apparently, at one point pay someone to build that glue, and then threw it out and wouldn't let the author release it so he's been reimplementing it out of...spite? Burning desire? Unclear. [1]
I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.
HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you.
But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large enough to get personalized attention from their engineers.
This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.
mnau 20 hours ago [-]
HIP was such a self-own and clear demonstration of AMD software capabilities... well, the lack of software capabilities. HIP was hard-coded for one GPU architecture. CUDA did it right, it has a intermediate virtual assembly PTX and driver compiles it to whatever actual instruction set card actually uses.
Imagine a meeting where they signed off on that. So each developer will have to provide a different binary for each of our architectures? Yep. And once we release the new architecture, developer will have to recompile his program for the new architecture? Yep. Sounds good to me.
hgoel 18 hours ago [-]
Yes, that was in part why they've had such a terrible history with GPU support.
They lost me as a customer when they rushed dropping support for the Radeon VII because of the need to ship binaries for every ISA, and didn't deliver proper 5700XT support until it was outdated.
A non-default-installation set of AMD tools (Ryzen Master and probably others) had an auto-updater which used HTTP instead of HTTPS. It's clear this is a feature they'd basically forgotten about; it even pointed to an ATI domain. A third-party bug bounty company rejected it because MITM was out of scope. AMD are incompetent at making software (news at 11), kept asking for extensions, and took an incredible amount of time to deal with it. Eventually they removed this updater entirely and replaced it with one in the app (rather than the installer) that uses HTTPS + a CRC32 (for some reason). The initial vuln was very stupid and should have been fixed faster. As for the current system, if you're mad about HTTPS-protected auto-updaters (which is valid), you've probably got a lot of them to go to war against.
asveikau 23 hours ago [-]
> 124 days to get AMD to add an s to a couple of HTTP URLs!
I disagree that they should only add HTTPS and call it done. They should also add some kind of signing check before running the payload.
If anything I'd say HTTPS is optional if they do that part.
Avamander 6 hours ago [-]
You'd imagine they'd just reuse and verify the Authenticode signature the very least.
The last time I remember, the green company did the same HTTP thing literally with their driver downloads from the website, and refused to fix it.
Makes me wonder, how much of that 4 month delay was spent deliberating with the state actor. As if there was Prism, and both companies were legally bound to allow MitM to happen, and thus don't have a bug bounty for it.
nyanpasu64 10 hours ago [-]
It doesn't smell like a state actor to me, just gross negligence. Brushing up on the Reddit comment we wrote, the MITM isn't exploitable by default, since the client will error out at the 301 redirect and leave an obvious black window on the user's desktop. Exploiting a user would require replacing the 301 redirect with a direct download, which requires the same amount of effort whether the default disclosure was broken or not.
Now if they could've started shipping a modified AMD auto update that followed redirects, that would allow them to pwn users of the updated program. But it would do nothing to people who had installed older versions, up to the version the author installed (which left a black window open indicating the downloads never completed)...
RandyOrion 15 hours ago [-]
Hilarious read. I laugh out loud multiple times during the read. In the end, I think amd should pay the author simply for the will of debugging for a broken software written by amd, as well as the sheer amounts of loose ends this exploration leads to.
stuaxo 8 hours ago [-]
Oof, the list of all the unpaid bounties is bad.
I'd make it worse by having the amount next to each and a running total.
robotnikman 19 hours ago [-]
Well that explains why I get that random console pop up from time to time, thanks for the insight into what's going on!
protocolture 20 hours ago [-]
AMD, just pay the man.
You want this stuff disclosed to you.
Dwedit 1 days ago [-]
There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.
If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.
leecommamichael 1 days ago [-]
Thank you for looking into this, I also have the annoying pop-up and have been suspicious of it…
greenavocado 1 days ago [-]
Congratulations, you found the government backdoor!
brikym 19 hours ago [-]
Glowing!
1 days ago [-]
xyst 24 hours ago [-]
Multi billion dollar company, by the way.
LearnYouALisp 18 hours ago [-]
I say the same when I dealt with Amazon's website, and to a smaller extent eBay.com. Don't forget Facebook Marketplace.
helterskelter 20 hours ago [-]
Jesus after reading this I'm wondering if I want to switch my AMD Framework 13 Pro order to Intel, but the IME runs on Java if memory serves and it's not like they'll be any more secure.
I just hope we can get Libreboot working with Framework sometime.
ForOldHack 22 hours ago [-]
Let this lesson be learned: "In my frustration, I decided to punish this software by decompiling it to figure out how it worked,"
Note to self: Never piss off a programmer, while he is gaming. To quote: "You're gonna die for that." -Duke Nukem.
dmitrygr 1 days ago [-]
I think we can all agree that MiTM is a valid attack vector and this should have paid out the bounty. AMD won't do it, but perhaps we can crowdsource it - the dude deserves it. Join me in doing this: https://ko-fi.com/mrbruhh (identical link to the one in the write up, feel free to verify).
I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.
My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.
That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.
But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!
LooseMarmoset 1 days ago [-]
Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.
The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.
Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux
somat 18 hours ago [-]
There is something wrong with the internal fan curve on my old rx580 as well. I ended up writing a controller to manually set the fan speed via the /sys interface.
I still need to figure out why the internal curve is not working, but have not gotten around to it because I like my controller so much. The novel bit is that as I was writing it I had an epiphany "Why a curve? What we really want is to close the loop. Set an ideal temperature and figure out the fan speed to maintain it" So my controller has a cute little PID loop to do just that. realistically it never works as I imagined. At idle the temp is lower then the set point at the slowest fan speed and at load the full speed fan keeps it ~ 10C higher than the set point(perhaps this means my set point should be higher?). but sometimes I get that goldilocks midrange load and it works great.
rirze 1 days ago [-]
Seems like white hat work is pretty fruitless nowadays. Disappointing.
inigyou 1 days ago [-]
They keep choosing to work whitehat instead of blackhat, which is all AMD ever wanted.
thesuitonym 1 days ago [-]
Gaslighting does not mean lying.
happytoexplain 1 days ago [-]
Yeah, it's annoying. But it's been captured by popular culture as meaning a blatant lie - one where the liar knows the truth is or was available/obvious. A "don't piss on my leg and tell me it's raining" lie.
Or, alternatively, and especially in gender relations, any lie intended to manipulate or demean another person. As opposed to lying to protect yourself, to swindle somebody, or some other reason. This is closer to the original idea, but still not there.
sakkura 1 days ago [-]
Such a bug could have been exploited by certain big state actors.
Those that have access to international network links.
Those that have the ability to generate new firmware that simply passes the CRC32 checksum.
tptacek 1 days ago [-]
A bug in a nonfunctional autoupdater. Big state actors. Got it.
Rendered at 18:37:51 GMT+0000 (Coordinated Universal Time) with Vercel.
So solves the MITM, but massive infection is still trivial if someone compromises the webserver.
Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?
The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private key. You don't need to do fancy things like global certs, discoverable keys, or revocation lists.
If today's installation doesn't have those checks and relies solely on HTTPS... well, that's unfortunate, but it's not like it poses a tricky dilemma! You simply use today's not-so-secure mechanism to install the new code which has more-secure behavior, and it closes the attacker's window of (easier) opportunity.
The current installation was fetched via HTTPS, right? Either by you or in the factory.
Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere
A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised.
B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com .
C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy.
Those are all interesting to contemplate, but they are at best "out of scope".
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.
I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now. Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence.
As things stand, I'm not sure key rotation would go well... the updater doesn't mind itself, apparently.
I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.
Everyone's judging this by the standard of "how good a bug" this is. But that's not necessarily how a bug bounty should function. Important prior to frame this with: neither any individual bug bounty submission nor the sum of all valid submissions materially alters the security of a serious product, at least not on their own. The system they feed into (for instance: security engineers taking a validated bounty submission and then quickly auditing the entire tree for variants of the same bug) can move the dials. The bounty bugs themselves though are mostly a sideshow.
What's especially weird (you didn't say this, but the sentiment has popped up on all 3 threads about this story) is the idea that AMD would be trying to cover this up. Why would they care? They run a bug bounty program. They've accepted the premise that they have vulnerabilities.
(From earlier today, in add'n: https://news.ycombinator.com/item?id=48492908).
Cards on the table I am not a fan of bug bounty programs, and the fact that they're an engineering process that turns out to be impossible to have public engineering discussions about is definitely one of many reasons why. Most companies should not run bug bounty programs.
MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.
I've never heard of most of them. AAA Certificate Services? AC RAIZ FNMT-RCM? ACCVRAIZ1? Actalis? AffirmTrust? Even Godaddy is in there. I know I don't trust those guys.
Trust has gotta start somewhere. But its much better to TOFU, then pin signing keys in the updater.
Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned.
The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want.
Although I suppose the aforementioned problem has significant implications beyond dns…
Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.
It has literally cost them a Trillion dollars in market cap - Nvidia's CUDA is a big reason they're so much bigger than AMD.
Thought this was par for the course in closer-to-hardware engineering.
Never understood why the objectively way harder jobs pay so much worse as an industry.
> a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms.
Companies reject bugs as out of scope and/or sit on them forever, then use the bug bounty ToS as intimidation to keep people from disclosing them. And sadly, it works.
I'm adding AMD to my list of companies that prefer their bug reports to be a public full disclosure rather than attempting to go through their bug bounty program.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
That’s my take.
So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.
Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.
From stackoverflow:
Because a 32-bit CRC yields only 2³² (approx. 4.29 billion) possible outputs, the Birthday Paradox dictates a 50% chance of an accidental collision after processing just ~77,000 unique inputs.
I've done it for shits and giggles and from memory it took my desktop PC maybe 10 minutes to generate a collision.
You're missing the point though.
Noise is not the only thing they should be protecting against.
The point is that AMD is executing code based on checking using an algorithm that has barely any protection from malicious inputs, which is stupid, and not fixing it just compounds that stupidity.
A cryptographic signature protects against both noise and malicious inputs.
Different tools for different purposes. You probably don't want to be using your mac scheme for noise resistance, because then you're paying a cost in either buffer space, PDU size, or retransmits, and your error correction capabilities are nil. CRCs allow some error correction (albeit rarely used and inefficient for multibit errors vs FECs), good bit error detection properties, and are cheap. It's common to use both at different layers of a protocol stack.
Remember that at giant tech companies, the incentive is to pay out bounties --- there are people on the vendor's team whose performance is measured in part by how much the program pays out.
I've written about this before here, but to sum it up:
* Unless something wild happens in software engineering (formal methods, &c) as a result of AI, there's no such thing as eradicating security vulnerabilities. Focused programs can eliminate low-hanging fruit, but at the point where you're offering significant bounties part of the premise is that all that fruit has been plucked. The marginal security impact of a single bounty award, by itself, is immaterial.
* What bounty programs can do is focus internal engineering attention. Large product teams have huge backlogs of issues and security design punch lists. For features and feature bugs, there's a closed loop that prioritizes the work: the market. For security vulnerabilities, bounties serve a similar purpose. This is why many bounties are tightly scoped; the whole point of the program is to direct the efforts of specific product teams.
* When we're talking about 10,000+ person engineering teams, the most important thing to know about bug bounty programs is that the company is incentivized to pay out. No major tech company that runs a bounty is "covering up" vulnerabilities. There's no reason for them to do so. They're running a program that ostentatiously pays rewards to people who report vulnerabilities! There are people on the teams managing the bounties who in effect get paid more when the program pays out more: that's what success looks like.
You add all this stuff up and all the drama about AMD (or Google or whoever) being shady or stingy basically never add up.
Nobody but AMD gives a fuck about AMD's internal policies or motivations.
If you don't care about AMD, why are you white-knighting AMD and defending AMD's bad behavior?
But, hey, OK, let's not make it about AMD specifically. It doesn't matter what any company thinks the purpose of its program is, nor does it matter what scope any company unilaterally decides to set for its program. What the outside world is going to see is whether or not you ignore security bugs. Your weird arcane internal policies, justifcations, and "scopes" are irrelevant. And, although I don't honestly care much about "security researchers", you can't really expect them to keep track of your private set of scope rules either... assuming you even tried to tell them the rules in advance to begin with.
My motivation here is very simple: I think people dunking on AMD's bounty program here mostly don't understand how bug bounties function. You apparently keep track of my comments on HN, so I think you know that's a beat I have here.
We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs and reduction of overhead initiatives thinking that the solution is to convince everyone you do payouts, but actually minimize payouts, which you could do by creatively using scopes.
We also regularly see how the incentives we see as outsiders (and somewhat insiders) are regularly perverted. For the VW emissions scandal someone could have argued that the incentives were plain and clear, "Design better engines", but they instead went with "Design better ways to scam the tests". This is on top of the way companies will mask their true incentives, like how renewable energy programs are sometimes actually just the smart financial decision but it'll be portrayed as part of the green movement.
To include some explicit personal opinion, I can't throw a stone without hitting a news story about a company that thought they could get away with something but then eventually got called out by it... and they ultimately still got away with it.
It was a pop culture example of incentives gone wrong to hopefully support why incentives aren't clear cut.
[1] - https://news.ycombinator.com/item?id=46906947
Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.
Works great!
For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.
They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most
Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?
Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money
As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point
my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.
Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)
But despite that, I also believe AMD would be better off just implementing CUDA.
I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.
[1] - https://vosen.github.io/ZLUDA/blog/zludas-third-life/
But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large enough to get personalized attention from their engineers.
This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.
Imagine a meeting where they signed off on that. So each developer will have to provide a different binary for each of our architectures? Yep. And once we release the new architecture, developer will have to recompile his program for the new architecture? Yep. Sounds good to me.
They lost me as a customer when they rushed dropping support for the Radeon VII because of the need to ship binaries for every ISA, and didn't deliver proper 5700XT support until it was outdated.
A non-default-installation set of AMD tools (Ryzen Master and probably others) had an auto-updater which used HTTP instead of HTTPS. It's clear this is a feature they'd basically forgotten about; it even pointed to an ATI domain. A third-party bug bounty company rejected it because MITM was out of scope. AMD are incompetent at making software (news at 11), kept asking for extensions, and took an incredible amount of time to deal with it. Eventually they removed this updater entirely and replaced it with one in the app (rather than the installer) that uses HTTPS + a CRC32 (for some reason). The initial vuln was very stupid and should have been fixed faster. As for the current system, if you're mad about HTTPS-protected auto-updaters (which is valid), you've probably got a lot of them to go to war against.
I disagree that they should only add HTTPS and call it done. They should also add some kind of signing check before running the payload.
If anything I'd say HTTPS is optional if they do that part.
Don't bother to use Windows?
Makes me wonder, how much of that 4 month delay was spent deliberating with the state actor. As if there was Prism, and both companies were legally bound to allow MitM to happen, and thus don't have a bug bounty for it.
Now if they could've started shipping a modified AMD auto update that followed redirects, that would allow them to pwn users of the updated program. But it would do nothing to people who had installed older versions, up to the version the author installed (which left a black window open indicating the downloads never completed)...
I'd make it worse by having the amount next to each and a running total.
You want this stuff disclosed to you.
If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.
I just hope we can get Libreboot working with Framework sometime.
Note to self: Never piss off a programmer, while he is gaming. To quote: "You're gonna die for that." -Duke Nukem.
I started it with $100 - https://ko-fi.com/transactions/03df753c-09b0-4972-8e53-adf06...
I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.
My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.
That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.
But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!
The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.
Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux
I still need to figure out why the internal curve is not working, but have not gotten around to it because I like my controller so much. The novel bit is that as I was writing it I had an epiphany "Why a curve? What we really want is to close the loop. Set an ideal temperature and figure out the fan speed to maintain it" So my controller has a cute little PID loop to do just that. realistically it never works as I imagined. At idle the temp is lower then the set point at the slowest fan speed and at load the full speed fan keeps it ~ 10C higher than the set point(perhaps this means my set point should be higher?). but sometimes I get that goldilocks midrange load and it works great.
Or, alternatively, and especially in gender relations, any lie intended to manipulate or demean another person. As opposed to lying to protect yourself, to swindle somebody, or some other reason. This is closer to the original idea, but still not there.
Those that have access to international network links.
Those that have the ability to generate new firmware that simply passes the CRC32 checksum.