Wednesday, March 14th 2018

CTS Labs Sent AMD and Other Companies a Research Package with Proof-of-Concept Code

CTS Labs, the Israel-based IT security research company behind Tuesday's explosive AMD Ryzen security vulnerabilities report, responded to questions posed by TechPowerUp. One of the biggest of these, which is also on the minds of skeptics, is the ominous lack of proof-of-concept code or binaries being part of their initial public report (in contrast to the Meltdown/Spectre reports that went into technical details about the exploit). CTS Labs stated to TechPowerUp that it has sent AMD, along with other big tech companies a "complete research package," which includes "full technical write-ups about the vulnerabilities," "functional proof-of-concept exploit code," and "instructions on how to reproduce each vulnerability." It stated that besides AMD, the research package was sent to Microsoft, HP, Dell, Symantec, FireEye, and Cisco Systems, to help them develop patches and mitigation.

An unwritten yet generally accepted practice in the IT security industry upon discovery of such vulnerabilities, is for researchers to give companies in question at least 90 days to design a software patch, harden infrastructure, or implement other mitigation. 90 days is in stark contrast to the 24 hours AMD got from CTS Labs. CTS Labs confirmed to TechPowerUp that it indeed shared its research package with AMD (and the other companies) just 24 hours prior to making its report public, but urged those disgruntled with this decision to look at the situation objectively. "If you look at the situation in the following way: right now the public knows about the vulnerabilities and their implications, AMD is fully informed and developing patches, and major security companies are also informed and working on mitigation."
This is in contrast to the unintentional consequence of keeping Meltdown/Spectre away from the public domain for over half a year, allowing Intel's senior executives to dump company stock, and for big cloud computing providers to harden their infrastructure, giving themselves a competitive advantage over smaller providers. But unlike with Meltdown/Spectre, these vulnerabilities aren't industry-wide (i.e. they don't affect Intel), placing AMD at a disadvantage in both the stock markets, and in the retail markets.

CTS Labs, through the sequence of its actions, has attempted to shift the burden of proof from itself to AMD, which is extremely uncommon in the IT security industry. With the lack of proof-of-concept of these vulnerabilities in the public domain, an environment of fear, uncertainty, and doubt (FUD) is being developed, with AMD being occupied with testing its chips for these vulnerabilities, and still far away from releasing patches, if the vulnerabilities are real. This places anyone with a shorting position against AMD stock at a distinct advantage. The strategy of AMD investor relations and corporate communications should now be to allay many of those fears among people without access to the proof-of-concept, and to ask investors to refrain from giving in to FUD.
Add your own comment

93 Comments on CTS Labs Sent AMD and Other Companies a Research Package with Proof-of-Concept Code

#51
newtekie1
Semi-Retired Folder
KaotikYes, but you still need to get that admin access to do the BIOS update/modification and at that point your system is already compromised, no matter whose CPU or chipset or whatever is in there. Also, since they blame it on American Megatrends making things easy, it should apply to any system with their BIOS?
Yes, you are currently screwed if you get the point that the hackers have admin access. However, normally a drive wipe and re-install will unscrew you, but not anymore. See the big problem?
Posted on Reply
#52
jabbadap
BonesCan we just stop with the anti-semitic crap already?
Ain't helping.
CTS couple of former IDF unit 8200 workers, AMD makes their chips on GF subsidiary owned by Arabs. Not saying these are really relative or Israel have anything to do with this. But you can't blame anyone to start conspiracy theories within such connections.
Posted on Reply
#53
Patriot
dicktracyThe AMD defense force doesn’t have a single evidence to debunk their findings. It may be fake it may be real. But let’s hide this because it hurts mah favorite brand.
www.servethehome.com/bizarre-amd-epyc-ryzen-vulnerability-disclosure/
I have reached out to several security contacts waiting to hear back, smells dirty but still worth investigating regardless of motives of CTS-Labs, CTSlabs or CTS...
Posted on Reply
#54
Vya Domus
dicktracydoesn’t have a single evidence to debunk their findings.
There isn't yet any evidence that those finding are true. But there are certainly details which make them seem not to be , such as :

- unknown security firm founded in 2017 finds out a massive amount of security flaws in record time likely requiring detailed inside information from AMD themselves about their chips
- "whitepaper" which contains close to zero technical information
- a site which looks like a joke full of FUD
- cringy buzzfeed type videos "explaining" the issues
- another individual which seems related to all this crap made another shady looking paper the very same day mentioning these findings and talking in detail about stock prices , market share and such

But , I know , none of these spark even a trace of doubt.
Posted on Reply
#55
D.Crepit
While everyone is speculating on this "revelation",
did we notice who did not get the package???

Rather telling don't you think?

Why didn't the Linux foundation receive it?
They're usually the first to come out with
corrective code. If we're doing a "public service"
why not give it to the parties most likely to
correct the problem first? Oh... it becomes
open source and everyone gets to see what
it is... or isn't... anyone ever try to get root
access on a Linux box lately?
Posted on Reply
#56
EarthDog
We'll see the CVE's come out for these soon enough. ;)

Once the dust settles, it will be fun to see who's left standing in the circle with their pud in hand. :)
Posted on Reply
#57
Tumbler1987
I would recommend waiting for an official response from AMD before calling shenanigans on these vulnerabilities, the extent of potential damage that can be caused by exploiting said vulnerabilities isn't known or corroborated by the actual manufacturer of the affected products, so I'm holding on passing any judgement for the time being.

I appreciate W1zzard's input on the matter, as he is well capable of making an educated guess on whether this is a real issue or not.

As far as all the conspiracy theories already being proposed, everyone has a right to express their opinion, but let's keep the facts in check, these news were only published less than a day ago, and some of the accusations and finger pointing are already getting out of hand.

Yes, we do live in an era when estate sponsored high level manipulation of public opinion is a real thing, but I'm sure in the days to come we'll get a more clear understanding of the motives behind the unorthodox way these vulnerabilities were revealed.

In the meantime, all we can do is hope no one can take advantage of the weaknesses exposed, that's the last thing we need now, as AMD is barely again becoming a force to be reckoned with in the CPU space, and the real consequences of whether their latest products can be easily hacked or not, will have a definite effect on everyone involved in this industry, AMD, ARM and even on how Intel can potentially play this in their favor and we would return to an age of progress staganation in CPU development, that's the last thing we all need.
Posted on Reply
#58
owen10578
W1zzardIt looks sufficiently credible to me to not ignore it, which is why we are reporting on this at TPU. You are right of course that more evidence is needed, which doesn't seem that far away, days at max, probably hours.

I feel I have an excellent understanding of what they described and am trying to provide insights, and help clear up misunderstandings.
Yes we definitely need more clarification before believing anything. So everyone should take it with a grain of salt.
Posted on Reply
#59
Vya Domus
EarthDogWe'll see the CVE's come out for these soon enough. ;)
Or not , that's another thing about it. Meltdown had a CVE entry a year before all of it became widely known , yet another reason not to take this too seriously.
Posted on Reply
#60
dozenfury
I wonder what would happen to a company if it ended up coming out that this was paid for/sponsored by a direct competitor to harm AMD. I can't imagine what the FCC penalties would be or the size of the lawsuits.

These requiring admin access are the same reason Meltdown and Spectre have had very little impact so far. Some of those S/M vectors even required physical local access. An attacker needing either admin or physical access (and even both in some cases), it's hard to get too fired up about it. It's a bit like saying if you leave your car unlocked, doors open, and leave your keys in the ignition...your car has a security vulnerability to being stolen. Generally speaking all bets are off if you give someone admin access since they can do anything then. SE-enabled Linux limits things (and it would have stopped Snowden btw), but it takes something like that. With Windows, admins pretty much have the keys to the kingdom to do what they want on that system.
Posted on Reply
#61
EarthDog
Vya DomusOr not , that's another thing about it. Meltdown had a CVE entry a year before all of it became widely known , yet another reason not to take this too seriously.
I know sites who talked with CTS. They are waiting on CVE numbers as they have not done a public disclosure of vulnerabilities before.

I'll post a link later tonight when it is published. ;)
Posted on Reply
#62
xorbe
EarthDogI know sites who talked with CTS. They are waiting on CVE numbers as they have not done a public disclosure of vulnerabilities before.
But 16 years of security industry experience!
Posted on Reply
#63
Yorgos
dicktracyThe AMD defense force doesn’t have a single evidence to debunk their findings. It may be fake it may be real. But let’s hide this because it hurts mah favorite brand.
There's nothing to defend here when there are zero evidence and obviously the whitepaper barely makes any sense. You need a signed bios in one attack to run the malicious code.
It's like saying that MS is potentially distributing malware, because they sign their and their partners' drivers with a key and if that key is available, then you could sign your malware and spread it as MS software.
This has happened before and the key was published by mistake by microsoft... that's how you get those rights to produce and run signed s/w.
BonesCan we just stop with the anti-semitic crap already?
Ain't helping.
What has this become, the JIDF?
The guy said that Jew politics are shady, and reality shows that they claimed Palestine's land as theirs, they built a Wall to keep the natives away from their territory, they keep expanding their borders with various methods, including bombing and they kill on sight anyone who seems not to happy about those israeli soldiers who walk around with rifles.
You should not disagree with the jews, goy, that's antisemetic.:kookoo:
W1zzardMalware, through same methods that infects thousands of PC each day.
You have 0, that's zero, idea what you are talking about. Malware is many things, it's adware, trojan, virus, rootkit. Most malware doesn't run with root priviledges in many systems, it just needs a certain type of privileges to do its work. Most malware doesn't get planted magically on a PC, and it is usually a user's fault.
I could go on and on, but it's a lost cause, with people who have already shaped opinions and specific dislikes, not even mentioning the theoretical background.
Anyhoo, here's a simple example about the "rm -rf /" malware.
System: Loonix distro w/ systemd.
Systemd mounts Bios partitions in /dev/ and some versions mount it with write privileges for the root user...
If you "run rm -rf /" , you delete parts of your memory mapped bios. what does this mean? It means for for the motherboard to get bricked.
2 bios chips? you have a great chance that you will get it to POST in the next reboot.
1 bios chip? either you have to bring your soldering iron, or try an SPI programmer and there might be a chance for that motherboard.
How does this example align with the current situation?
You could for example take that file pointer from /dev/ and fill it with your "crafted bios"
then from the paper:
>Exploiting MASTERKEYrequires an attacker to be able to reflash the BIOS with a specially crafted BIOS update
nice, and how do you do that
>we suspect an attacker couldoccasionally still succeed in reflashing the BIOS
"suspect"... so you are not very sure.
let's go forth
>This could be done by first exploiting RYZENFALL or FALLOUT
nice, so I have to read Ryzenfall (that's a big claim there on the name) first
let's go to Ryzenfall's technique.
>Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed
What?
So you tell me that asrock, asus, asmedia, american bios, can haz malware with their AMD supplied key?
so, you get the sign, you sign your code and this means that you can have either some microcode running on the cpu in ring -X, or on the bios itself.
How do you obtain the key? well someone has to provide it to you.
So there's no flaw there, a CPU, a peripheral, an embedded system _must_ run digitally signed firmware.
Where's the flaw? I have no idea? MS mistakenly had debug symbols on one of their supplied drivers, they lost a key, they invalidated it and its past.... we had good laughs.

But how come the almighty hack4z0rd W2zzard come up with "malware?
let's see the paper: a 20 page whitepaper that has zero facts, many mistakes, some ridiculous assumptions and some repetitive charts has 32 occurrences of the word "malware".
They are talking about the Arm Trustzone security "flaws", which ofc you have to exploit(if any) in order to gain access to the AMD PSP processor and there's hardly any mention of "Arm flaw".
There's some claim on twitter by one of the CTS guys, that ASMedia has an open windows on their firmware and there's no "ASMedia flaw" (they even say that asmedia's flaw exists because a few years ago asmedia lost a key :facepalm: )

conclusion:
there are some people out there, like w2zzard, who feel that it is their duty to bash some companies... and this has an impact on their sites. I found this thread because w2zzard wrote what he thinks is plausible, backlinks to amdflaws.com, then amdflaws.com backlinks here to say that this is a credible source(someone's opinion) so go read the "article on tpu or vice( :puke: ) or other yellow sites.
If there's some PoC that does this, e.g. they get the key from a signed f/w with debug symbols still on the binary( doubt it coz of many embedded system reasons), then you just gain the ability to talk to the cpu. the Arm trustzone and the AMD PSP is well documented on some extend, therefore there's no "security by obscurity" as e.g. in the Intel ME where they didn't even said to the people that they ran on minix.
Unlike the PSP, ME has security flaws, that's why they found many parts of that system, that's how they found the OS it's running, the TCP/IP stack and so forth... that's how the documentation for the ME was written.
Arm trustzone IPs and f/w is available for purchase via Arm holdings. There's nothing to hide, the system has perfect documentation and there's a sh-tload of companies using it and debugging it. You set your own key and the system is secured.
That's a totally different approach and to be quite honest security by obscurity was a method they used in the 50s and 60s.

bonus:
the fail overflow team managed to get priviledges on the ps4 to run linux. how did they did it? there's a video on yt about this. The most interesting thing is that they had physical access to the board, a soldering iron, cables, programmers and a southbridge that was not made by AMD and had privileges to do IOMMU/DMA with the cpu.
They could easily claim "amdead" "ambankrupt" "$0 stock value" and what not, but they are professionals, first, and foremost they are people who have the background to do such exploits.
They knew it's not a Jaguar flaw when your southbridge rights on the memory of the system which is supposed to alter.

grats TPU, you gained, for another time, a few cheap Clicks.
clap();
wait(2000);
clap();
wait(2000);
clap();
return;

P.S.: I might be a Jew, you don't know. Disagreeing with me makes you an potential anti-semite. How does that make you feel? How are you going to sleep tonight?
P.S.: I wonder if there's an occurrence of code running so close to the metal and called malware. If my memory serves me right, this term is not used in bare metal situations and requires an OS and a security flaw to be called malware by researchers (those who submit papers, not those with a credit card and internet access to namecheap for a domain), but I am not sure. Food for thought anyways. See ya in several years again when another bubble hits the market.
Posted on Reply
#64
john_
CTS Labs says they didn't share technical information about how to take advantage of these vulnerabilities, so hackers don't use these vulnerabilities.

Considering how much they tried to make themselves known to about everyone, how hard they try to destroy AMD's image and the fact that Viceroy research had information in advance, I am fearing that all technical information needed to take advantage of those vulnerabilities are already at the hands of very nasty people who are going to start the second attack to AMD pretty soon. That would be probably an attack on a company or organization using AMD hardware (AMD themselves should take extra steps of securing themselves). I wouldn't be surprised if we learn soon about a security breach where Ryzen systems where compromised.
Just a thought.
Posted on Reply
#65
Kaotik
john_CTS Labs says they didn't share technical information about how to take advantage of these vulnerabilities, so hackers don't use these vulnerabilities.

Considering how much they tried to make themselves known to about everyone, how hard they try to destroy AMD's image and the fact that Viceroy research had information in advance, I am fearing that all technical information needed to take advantage of those vulnerabilities are already at the hands of very nasty people who are going to start the second attack to AMD pretty soon. That would be probably an attack on a company or organization using AMD hardware (AMD themselves should take extra steps of securing themselves). I wouldn't be surprised if we learn soon about a security breach where Ryzen systems where compromised.
Just a thought.
First part yes, second part no. Their POC's will still require those admin accesses and signed malicious drivers or signed malicious BIOS - if those "nasty people" could use them, those systems would have been compromised beforehand and it doesn't matter if they had the POCs at hand or not, they would still do nasty stuff
Posted on Reply
#66
Yorgos
john_CTS Labs says they didn't share technical information about how to take advantage of these vulnerabilities, so hackers don't use these vulnerabilities.

Considering how much they tried to make themselves known to about everyone, how hard they try to destroy AMD's image and the fact that Viceroy research had information in advance, I am fearing that all technical information needed to take advantage of those vulnerabilities are already at the hands of very nasty people who are going to start the second attack to AMD pretty soon. That would be probably an attack on a company or organization using AMD hardware (AMD themselves should take extra steps of securing themselves). I wouldn't be surprised if we learn soon about a security breach where Ryzen systems where compromised.
Just a thought.
I think this will help a lot of people

This is supposedly one guy who has seen some code that does the trick on the Zen cpus.
What he says here, is that we are looking at some s/w exploit, not even related to the Zen architecture.
KaotikFirst part yes, second part no. Their POC's will still require those admin accesses and signed malicious drivers or signed malicious BIOS - if those "nasty people" could use them, those systems would have been compromised beforehand and it doesn't matter if they had the POCs at hand or not, they would still do nasty stuff
the only way this can happen is one of the keys to be slipped outside of some OEM's sandbox(paid shills? corporate spies? id1ots?).
Don't forget that Arm trustzone and AMD PSP have no hardwired keys on their silicon.... unlike other approaches.
Posted on Reply
#67
Tumbler1987
YorgosThere's nothing to defend here when there are zero evidence and obviously the whitepaper barely makes any sense. You need a signed bios in one attack to run the malicious code.
It's like saying that MS is potentially distributing malware, because they sign their and their partners' drivers with a key and if that key is available, then you could sign your malware and spread it as MS software.
This has happened before and the key was published by mistake by microsoft... that's how you get those rights to produce and run signed s/w.

What has this become, the JIDF?
The guy said that Jew politics are shady, and reality shows that they claimed Palestine's land as theirs, they built a Wall to keep the natives away from their territory, they keep expanding their borders with various methods, including bombing and they kill on sight anyone who seems not to happy about those israeli soldiers who walk around with rifles.
You should not disagree with the jews, goy, that's antisemetic.:kookoo:


You have 0, that's zero, idea what you are talking about. Malware is many things, it's adware, trojan, virus, rootkit. Most malware doesn't run with root priviledges in many systems, it just needs a certain type of privileges to do its work. Most malware doesn't get planted magically on a PC, and it is usually a user's fault.
I could go on and on, but it's a lost cause, with people who have already shaped opinions and specific dislikes, not even mentioning the theoretical background.
Anyhoo, here's a simple example about the "rm -rf /" malware.
System: Loonix distro w/ systemd.
Systemd mounts Bios partitions in /dev/ and some versions mount it with write privileges for the root user...
If you "run rm -rf /" , you delete parts of your memory mapped bios. what does this mean? It means for for the motherboard to get bricked.
2 bios chips? you have a great chance that you will get it to POST in the next reboot.
1 bios chip? either you have to bring your soldering iron, or try an SPI programmer and there might be a chance for that motherboard.
How does this example align with the current situation?
You could for example take that file pointer from /dev/ and fill it with your "crafted bios"
then from the paper:
>Exploiting MASTERKEYrequires an attacker to be able to reflash the BIOS with a specially crafted BIOS update
nice, and how do you do that
>we suspect an attacker couldoccasionally still succeed in reflashing the BIOS
"suspect"... so you are not very sure.
let's go forth
>This could be done by first exploiting RYZENFALL or FALLOUT
nice, so I have to read Ryzenfall (that's a big claim there on the name) first
let's go to Ryzenfall's technique.
>Accessing the Secure Processor is done through a vendor supplied driver that is digitally signed
What?
So you tell me that asrock, asus, asmedia, american bios, can haz malware with their AMD supplied key?
so, you get the sign, you sign your code and this means that you can have either some microcode running on the cpu in ring -X, or on the bios itself.
How do you obtain the key? well someone has to provide it to you.
So there's no flaw there, a CPU, a peripheral, an embedded system _must_ run digitally signed firmware.
Where's the flaw? I have no idea? MS mistakenly had debug symbols on one of their supplied drivers, they lost a key, they invalidated it and its past.... we had good laughs.

But how come the almighty hack4z0rd W2zzard come up with "malware?
let's see the paper: a 20 page whitepaper that has zero facts, many mistakes, some ridiculous assumptions and some repetitive charts has 32 occurrences of the word "malware".
They are talking about the Arm Trustzone security "flaws", which ofc you have to exploit(if any) in order to gain access to the AMD PSP processor and there's hardly any mention of "Arm flaw".
There's some claim on twitter by one of the CTS guys, that ASMedia has an open windows on their firmware and there's no "ASMedia flaw" (they even say that asmedia's flaw exists because a few years ago asmedia lost a key :facepalm: )

conclusion:
there are some people out there, like w2zzard, who feel that it is their duty to bash some companies... and this has an impact on their sites. I found this thread because w2zzard wrote what he thinks is plausible, backlinks to amdflaws.com, then amdflaws.com backlinks here to say that this is a credible source(someone's opinion) so go read the "article on tpu or vice( :puke: ) or other yellow sites.
If there's some PoC that does this, e.g. they get the key from a signed f/w with debug symbols still on the binary( doubt it coz of many embedded system reasons), then you just gain the ability to talk to the cpu. the Arm trustzone and the AMD PSP is well documented on some extend, therefore there's no "security by obscurity" as e.g. in the Intel ME where they didn't even said to the people that they ran on minix.
Unlike the PSP, ME has security flaws, that's why they found many parts of that system, that's how they found the OS it's running, the TCP/IP stack and so forth... that's how the documentation for the ME was written.
Arm trustzone IPs and f/w is available for purchase via Arm holdings. There's nothing to hide, the system has perfect documentation and there's a sh-tload of companies using it and debugging it. You set your own key and the system is secured.
That's a totally different approach and to be quite honest security by obscurity was a method they used in the 50s and 60s.

bonus:
the fail overflow team managed to get priviledges on the ps4 to run linux. how did they did it? there's a video on yt about this. The most interesting thing is that they had physical access to the board, a soldering iron, cables, programmers and a southbridge that was not made by AMD and had privileges to do IOMMU/DMA with the cpu.
They could easily claim "amdead" "ambankrupt" "$0 stock value" and what not, but they are professionals, first, and foremost they are people who have the background to do such exploits.
They knew it's not a Jaguar flaw when your southbridge rights on the memory of the system which is supposed to alter.

grats TPU, you gained, for another time, a few cheap Clicks.
clap();
wait(2000);
clap();
wait(2000);
clap();
return;

P.S.: I might be a Jew, you don't know. Disagreeing with me makes you an potential anti-semite. How does that make you feel? How are you going to sleep tonight?
P.S.: I wonder if there's an occurrence of code running so close to the metal and called malware. If my memory serves me right, this term is not used in bare metal situations and requires an OS and a security flaw to be called malware by researchers (those who submit papers, not those with a credit card and internet access to namecheap for a domain), but I am not sure. Food for thought anyways. See ya in several years again when another bubble hits the market.
Why so much vitriol? If you hate TPU so much, then you should read your tech news from other websites.

I should warn you though, get ready to be sorely disappointed, as the news on these flaws have been reported on almost every single reputable tech site, and even on non tech related news websites, so you'll have to deal with the fact that this is a newsworthy development, I would suggest avoiding reading about it if it rubs you in such a wrong way.

As far as W1zzard's credentials, he's been developing hardware level hacking tools since the days when Ati was still around, I remember using his OCing tools back when I had a Radeon 8500 in the early 2000s, so give the man some credibility, that gives him a fair advantage when formulating a well educated guess on the veracity of these alleged flaws.

Either way, this is a tech site, and TPU has every right to report on these very relevant news, they can't just turn a blind eye, or bury their heads in the sand while everyone else is reporting on it.

Idk why people are rushing to conclusions without even hearing from AMD, obviously this has caught the tech world by surprise, I strongly advise to wait for an official acknowledgement by AMD before formulating theories about the origins of the vulnerabilities, and the extent of damage we can expect from them if they're in fact real.
Posted on Reply
#68
EarthDog
I think he takes exception to the delivery here, not the news itself. ;)



Anyway, it may be a couple of days before we hear anything from AMD. As I understand things, third party validation took 4-5 days.

That said, I just noticed an update in the AT from this morning that may clarify one thing or another... or not.

Update 3/14 5:00am ET
Reported by Ars Technica, a second security firm has now spoken publicly about being contacted by CTS-Labs for verification of the vulnerabilities. Gadi Evron, CEO of Cymmetria, stated in a series of tweets that:
  1. He knows CTS-Labs and vouches for their technical capabilities, but has no knowledge of their business model
  2. All the vulnerabilites do not require physical access (a simple exe is all that is needed)
  3. Fallout does not require a reflash of the BIOS
  4. CTS-Labs believes that the public has a right to know if a vendor they are using makes them vulnerable, which is why no substantial lead time was given.
Quoted by Ars is David Kanter, founder of Real World Technologies and industry consultant, who verifies that even though these are secondary stage attacks, they can still be highly important. David states that while

[INDENT]"All the exploits require root access - if someone already has root access to your system, you're already compromised. This is like if someone broke into your home and they got to install video cameras to spy on you".[/INDENT]
Ars also quotes Dan Guido, who states that all that is needed to enable these exploits is the credentials of a single administrator:

[INDENT]"Once you have administrative rights, exploiting the bugs is unforunately not that complicated."[/INDENT]
[INDENT][/INDENT]
Posted on Reply
#69
Xzibit
I compare it to..

"Breaking an Entering" vs "Trespassing" your still not authorized to be there. Heck you can Trespass through a open door.

Well if i put a uniform and disguise myself as a cop (signed credentials) its okay right? What ever I do there after is there for a vulnerability.
FordGT90ConceptImpersonating a public safety officer has very severe penalties.
Going to put a lot of strippers out of work
Posted on Reply
#70
FordGT90Concept
"I go fast!1!11!1!"
Impersonating a public safety officer has very severe penalties.


How is Ryzen more adversely impacted than a Core i7 once root access is gained? In either case, I'd argue you already lost the war. Why do these 13 vulnerabilities matter at all? It's like comparing the aftermath of an ant invasion versus a earwig invasion. Full damage control mode response is more or less the same, no?
Posted on Reply
#71
R-T-B
RejZoRStill, when you have admin access, does it really matter at that point anymore?
When the malware can then survive a subsequent reinstall?

Yes.
srsbsnsThe real vulnerability right there. What if I told you there is a vulnerability in the wild that allows anyone to do anything to a system no matter the OS. Its called the login/password.
That's been false since "hardware security" became a thing.

Or, it was supposed to be.
D.CrepitWhile everyone is speculating on this "revelation",
did we notice who did not get the package???

Rather telling don't you think?

Why didn't the Linux foundation receive it?
They're usually the first to come out with
corrective code. If we're doing a "public service"
why not give it to the parties most likely to
correct the problem first? Oh... it becomes
open source and everyone gets to see what
it is... or isn't... anyone ever try to get root
access on a Linux box lately?
Because linux doesn't run on the PSP?
Posted on Reply
#72
Prima.Vera
All and all, I think this is good that all those vulnerabilities are disclosed now, or in the recent months, since all of those most likely were already known by the governments.
Posted on Reply
#73
R-T-B
Prima.VeraAll and all, I think this is good that all those vulnerabilities are disclosed now, or in the recent months, since all of those most likely were already known by the governments.
I'm less conspiritorial than that. I know, I know, they've hoarded vulnerabilities in the past, but I'd like to believe complex ones like this to be beyond their needs or desires.
Posted on Reply
#74
lewis007
EarthDogI think he takes exception to the delivery here, not the news itself. ;)



Anyway, it may be a couple of days before we hear anything from AMD. As I understand things, third party validation took 4-5 days.

That said, I just noticed an update in the AT from this morning that may clarify one thing or another... or not.


[INDENT][/INDENT]
My question is why give Intel a 6 month lead in with their vulnerabilities and not AMD, Im no security expert but why give a company like CTS so much validity when they themselves state on their website that they make money from the corporations they are investigating, if that isn't a red flag then what is?
Posted on Reply
#75
jabbadap
lewis007My question is why give Intel a 6 month lead in with their vulnerabilities and not AMD, Im no security expert but why give a company like CTS so much validity when they themselves state on their website that they make money from the corporations they are investigating, if that isn't a red flag then what is?
If you mean Spectre and Meltdown, those vulnerabilities was not just only in Intel's processors. Meltdown and Spectre were on IBM power 8/9 and some ARM manufacturers too. And Spectre was even on wider range of processors including AMD. And yes they were all given over the norm 90 days to respond on those vulnerabilities before making them public...

But yeah 24 hours is too short time to respond and makes all this very suspicious. Makes it feels like a stock manipulation scam disguised with real but not so severe vulnerabilities.
Posted on Reply
Add your own comment
Dec 22nd, 2024 09:27 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts