Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The RCE that AMD won't fix

mrbruh.com

Post reply on HN
Print view View original

141–150 of 182 posts

Re: The RCE that AMD won't fix

#141

Post by scott_w »

jbstack wrote: post #126
scott_w wrote: post #97

Earlier quoted context omitted.

Because that's not how corporate maths works. The comparison is not "what is the cost of this vs our current revenue?" The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?" Will fixing this issue bring in more revenue than ignoring it and building a new feature? Or fixing a different issue? If the answer is "no" then the answer is that it doesn't get fixed.

> The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?" I don't agree with this, because it pre-supposes that there's a limited number of engineers available. The question isn't "shall I pull engineer X off project Y so that he can fix security bugs?", it's "shall I hire an additional engineer to fix security bugs?". The comment above mine suggests the answer to t…

It doesn't matter: the equation is exactly the same. Why would you hire someone to work on a bug fix or security fix when you could hire that same person and have them work on something even more valuable again?

Re: The RCE that AMD won't fix

#142

Post by Delk »

tgsovlerkhgsel wrote: post #129
carefree-bob wrote: post #51

From the title, I thought this was going to be another one of those speculative execution information leakage bugs that are basically impossible to fix, but something this simple and easily fixable -- it's discouraging. Hopefully this decision is reversed. Also "Thank you for hacking our product" seems a bit unprofessional for someone engaging in responsible disclosure for a major security issue with your product.

"Thank you for hacking our product" sounds perfectly appropriate to me; it clearly uses "hacking" in the positive sense.

It actually says "hacking on one of our programs", which makes it even more obvious that it's using the word closer to the positive traditional hacker culture sense.

I'm sure that still looks unprofessional to some people, just like any jargon that isn't corporatese does.

Re: The RCE that AMD won't fix

#143

Post by jbstack »

scott_w wrote: post #141
jbstack wrote: post #126

Earlier quoted context omitted.

> The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?" I don't agree with this, because it pre-supposes that there's a limited number of engineers available. The question isn't "shall I pull engineer X off project Y so that he can fix security bugs?", it's "shall I hire an additional engineer to fix security bugs?". The comment above mine suggests the answer to t…

It doesn't matter: the equation is exactly the same. Why would you hire someone to work on a bug fix or security fix when you could hire that same person and have them work on something even more valuable again?

Now there's a related problem in the premise: it pre-supposes that the company has an unlimited amount of valuable work to be done. If that were the case, all companies would simply expand their workforce as much as possible all the time, only constrained by money running out (which itself would be an exponential increase since "valuable" work presumably leads to more money in future). In reality, companies do not prioritise expansion above all else. In fact any time a company pays a dividend to its shareholders, or otherwise refrains from spending cash reserves on new hires, it's recognising that it cannot invest profits in an effective way into its labour force.

When framed correctly (there's effectively an unlimited labour supply for most companies, and effectively a limited demand for staff) then the question becomes "shall we hire an engineer to fix security bugs when we don't need an engineer for anything else?".

Re: The RCE that AMD won't fix

#144

Post by hbn »

hhh wrote: post #133
M95D wrote: post #121

Earlier quoted context omitted.

And which are the companies that are good at software? Please, give at least one example.

Apple

Everyone's gonna give you shit for this answer and there's a hundred things I could tell you about their software that pisses me off, but the bar is so low for software these days, their stuff is still in the high end of quality (they need to do a lot to get back to where they were 10 years ago though)

Only other software I regularly use that I think is overall high quality and I enjoy using are the JetBrains IDEs, and the Telegram mobile app (though the Premium upselling has gotten kinda gross the past few years)

Re: The RCE that AMD won't fix

#146

Post by ZiiS »

zeendo wrote: post #123
ZiiS wrote: post #88

Earlier quoted context omitted.

I would use my phone's 'hotspot' long before I tried random wifi on my laptop?

Are you being willfully obtuse or do you actually believe that's true of everyone? There are so many reasons why someone might have a laptop in such a situation but not be able to use a hotspot on their phone - it's not even worth listing them.

That isn't what this thread suggested; I was supporting plausibility of the GP's claim never to have used public Wifi because of good 4G; stating they could still have used a laptop in public. My wording was also explicit that this isn't always an option.

Re: The RCE that AMD won't fix

#147

Post by Telaneo »

hhh wrote: post #133
M95D wrote: post #121

Earlier quoted context omitted.

And which are the companies that are good at software? Please, give at least one example.

Apple

They at least were good at software. The argument that they currently still are good at software is getting weaker and weaker.

Re: The RCE that AMD won't fix

#148

Post by lencastre »

scott_w wrote: post #97
jbstack wrote: post #91

Earlier quoted context omitted.

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

Because that's not how corporate maths works. The comparison is not "what is the cost of this vs our current revenue?" The calculation is "what could that engineer be doing instead and what is that worth vs fixing this issue?" Will fixing this issue bring in more revenue than ignoring it and building a new feature? Or fixing a different issue? If the answer is "no" then the answer is that it doesn't get fixed.

ah corporate meff, if the claim is lower than the recall cost, pay the claim

Re: The RCE that AMD won't fix

#149

Post by Stefan-H »

tgsovlerkhgsel wrote: post #127
tptacek wrote: post #55

Earlier quoted context omitted.

The only thing cited here is a response from their bug bounty program. Excluding MITM from a bug bounty is perfectly legitimate. Actually, excluding anything from a bounty program is.

Excluding severe vulnerabilities like ones that completely pwn your machine just by connecting it to an untrusted network is not legitimate for any reasonable bug bounty program. Of course, a company can do it (they just did!), but it shows that they don't care about security at all. Especially if the answer is "sorry this is out of scope" rather than "while this is out of scope for our bug bounty so we can't pay you…

Ethical disclosure existed before bug bounties. Someone who wants to ensure the remediation of the bug might recognize that the staff member responding to bug bounty reports is limited in their purview and might be badly trained. Upon learning that it is out of scope for the bug bounty program did the author try their security@ or another a referenced security contact?

Your characterization of this bug as one "that completely pwn your machine just by connecting it to an untrusted network" is also hyperbolic to the extreme.

Re: The RCE that AMD won't fix

#150

Post by 0x1ch »

hulitu wrote: post #100
Kodiack wrote: post #74

Earlier quoted context omitted.

Automatic updates are absolutely not peak stupidity. Most users’ devices would have nasty security vulnerabilities wide open for a much longer period of time without automatic updates.

This asuming Automatic updates fix security vulnerabilities, which is almost never the case.

Laughably ignorant update policies.
Post reply on HN