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.
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.
93 Comments on CTS Labs Sent AMD and Other Companies a Research Package with Proof-of-Concept Code
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...
- 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.
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?
Once the dust settles, it will be fun to see who's left standing in the circle with their pud in hand. :)
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.
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.
I'll post a link later tonight when it is published. ;)
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.
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.
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. 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.
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.
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]
"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. Going to put a lot of strippers out of work
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?
Yes. That's been false since "hardware security" became a thing.
Or, it was supposed to be. Because linux doesn't run on the PSP?
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.