LinkBack URL
About LinkBacksWell I've never done that....Originally Posted by infraction
Well I've never done that....
If I remember rightly there was an organised crime gang which intercepted a shipment of mobile phones (probably in China) and put malware on them. It was only one batch they got to but still, no one noticed for ages as you assume a phone you've bought from a shop is pretty much untouched from the manufacturer, everyone thought they were secure. It was a while back but frankly when you've got lorry drivers who are probably paid 3/5ths of nothing in somewhere like China, offering them a few grand in cash to "feel unwell and need to stop over at services overnight" whilst someone pokes at your cargo is not going to be hard to do. The lorry driver probably gets a life changing sum for their nappy nap.
Complete lies, and we know it from their actions - if it was unfixable, then they could have made more money. Just follow the standard process, and after 90 days you get to go public and shout "AMD has flaws, and they cannot fix them" with proof. That's bound to get more attention, and more effect on the share price. Their actual actions look like a textbook example of how to maximise the impact of a big nothingburger - all to generate the biggest splash in the month or so it takes AMD to fix any of the supposed vulnerabilities.CTS Labs told us that it bucked the industry-standard 90-day response time because, after it discussed the vulnerabilities with manufacturers and other security experts, it came to believe that AMD wouldn't be able to fix the problems for "many, many months, or even a year." Instead of waiting a full year to reveal these vulnerabilities, CTS Labs decided to inform the public of its discovery.
been thinking about how these exploits could work (its stevie theory time - makes sense if you think about it but probabaly wrong)
gigabyte has the @BIOS app that updates the bios from within windows. all you'd need to do is get a modified app that points to your server for update instead of gigabytes, voila modified bios.Masterkey (x3) vulnerabilities allow attackers to infiltrate the Secure Processor due to multiple vulnerabilities in the firmware. Exploiting MASTERKEY requires an attacker to be able to re-flash the BIOS with a specially crafted BIOS update.
this isn't just a ryzen roblem though. gigabtye also make intel boards that has @bios
again, generic stuff that affects all computers and the way they operate. and its the windows isolated memory affected, so why is this just on amds, surely intel can access that too?Ryzenfall (x4) allows malicious code to take complete control over the AMD Secure Processor. Exploitation requires that an attacker be able to run a program with local-machine elevated administrator privileges.
Fallout (x3) allows attackers to read from and write to protected memory areas, such as SMRAM and Windows Credential Guard isolated memory (VTL-1). Exploitation requires that an attacker be able to run a program with local-machine elevated administrator privileges
without knowing the specfics of why its just ryzens that are vulnerable, its just anti-amd talk to me. everythings affected if you have elevated admin access.
the picture underneath shows the asmedia usb3/3.1 chip. my quick google show this to be on everyboard that has usb3. so why are only amd affected and not intel that has the exact same chip?Chimera (x2) consists of two sets of manufacturer backdoors; one in firmware and another in hardware. Malicious code can be injected via these backdoors. Prerequisites for Exploitation are: a program running with local-machine elevated administrator privileges. Access to the device is provided by a driver that is digitally signed by the vendor
to me it looks very much like anti AMD talk, going 'look amd has problems too' people going 'oh yeah they do' 'boo amd', and hoping no one questions that these generic flaws affect every system ever.
its just a big distraction con-job to in my eyes, could be al that stock manipulation stuff mentioned. and until they actually say how these only affect amd, or amd themselves go 'oh yeah these are vulnerabilities' then these are my thoughts on it.
That, to be honest, is exactly the type of debate we aim for. We certainly don't want a debate where everyobe agrees. How boring would "I think <insert topic/opinion>" followed by a unanimous chorus of agreement, and me too's. It be a very short and ultra boring discussion.
I used to have some really good arguments in a rather rough pub. But we all respected each other's opinions. Good job really, 'cos if we'd started calling each other names, someone was likely to get bottled or clobbered with a broken chair leg. And that was just the ladies. It's amazing how the likelihood of a haymaker to the hooter encourages courtesy.
Hoonigan (16-03-2018)
Secure processors aren't like normal ones, they are supposed to have an unbroken trust chain from their fixed boot rom up to the final application they run. There is a tendancy for people to break the chain though, just look at any old games console.
I thought AMD were using an ARM trustzone implementation though, so I would have expected that to be OK. There must be some gnarly code where ARM meets amd64 though.
Still, for someone like me that switches secure boot off in the BIOS and installs Linux it all seems rather moot.
You need a good man with a haymaker to stop themAnd that was just the ladies. It's amazing how the likelihood of a haymaker to the hooter encourages courtesy.
Last edited by DanceswithUnix; 15-03-2018 at 08:11 AM.
Hardware Unboxed revisited the HD7970/R9 280X,but look at the comment they posted(not debating the accuracy here but it was funny):
https://www.youtube.com/watch?v=svxzrs8Dtq8
Something I left out of the video, I discovered that the Radeon R9 280X has had a serious exploit all this time and all Radeon GPUs might suffer this same vulnerability. If you plug a graphics card with the 280X GPU into your system and connect up a display and then let a stranger onto your PC, they might be able to steal your data and even flash your BIOS. This is particularly serious if you have a password to access your account, but give the stranger the password!
Sir, you have messed up. You embarrass yourself.
And no, I'm not an AMD fanboi/gurl/whatever. I haven't owned an AMD processor for about 10 years.
But apparently I'm a girl *swooshes hair Shia LeBouef style*
LOL:
https://www.extremetech.com/computin...gs-deeper-hole
It’s absolutely fair to characterize and test the flaws in AMD’s chipsets. But as CTS Labs’ white paper makes clear, the same Asmedia chips that make up AMD’s Promontory chipset for Ryzen CPUs have been shipping on motherboards, including hundreds of Intel motherboards models, for at least the past six years.
The Asmedia ASM1042 and ASM1142 were and are widely used on Intel motherboards, but CTS Labs neglects to mention that fact in its white paper or letter.
Zilberman tacitly acknowledges this when he writes:
[W]e have started researching ASMedia chips about a year ago. After researching for some time, we have found manufacturer backdoors inside the chip which give you full control over the chips (ASM1042, ASM1142, ASM1143). We wanted to go public with the findings, but then saw that AMD have outsourced their chipset to ASMedia. So we decided to check the state of AMD, we bought a Ryzen computer, and whimsically ran our exploit PoC, and it just worked out of the box.
By its own statements, CTS Labs tested and developed a proof of concept exploit for Asmedia controllers before it was aware these controllers were incorporated into Ryzen chipsets. Where, then, is the website AsmediaFlaws.com? Where’s the notification to tell Intel motherboard customers that the chips on their motherboards can be similarly backdoored and abused? This isn’t a theoretical; I’m writing this article from an Ivy Bridge-E system powered by an Asus X79-Deluxe motherboard with an Asmedia 1042 controller. In its white paper, CTS Labs describes the offending Asmedia controllers as follows:
In our assessment, these controllers, which are commonly found on motherboards made by Taiwanese OEMs, have sub-standard security and no mitigations against exploitation. They are plagued with security vulnerabilities in both firmware and hardware, allowing attackers to run arbitrary code inside the chip, or to reflash the chip with persistent malware.
If CTS Labs has accurately characterized these flaws, the problems in Asmedia controllers affect millions of Intel motherboards worldwide going back six years. In the early days of USB 3.0, before Intel added its own native chipset support, Asmedia was one of the most common third-party providers. Chips like the ASM1142 are still used on Intel motherboards today. When we looked at Newegg, nearly every USB 3.0 PCI Express card we spot-checked used an Asmedia solution — typically the ASM1042 or ASM1142.
If these Asmedia flaws are common to Intel, AMD, and standalone cards, Intel users and expansion card users absolutely should’ve been notified. If they’re unique to AMD users, CTS Labs needed to explain why. It has not. Again, when security researchers describe flaws, they typically describe them across the entire set of hardware on which they are known to occur. Failing that, they at least acknowledge the use of these broken solutions in other contexts. CTS Labs did neither.
Ok,I found this video on AT forums which was with Ian Cutress from AT and David Kanter talking with CTS-Labs:
https://www.youtube.com/watch?v=cj3_AILPvU0
A poster on AT forums who watched it said the following:
It's a long watch but there are some good details in there about the story and his call with CTS. Lots of questions he posed with no real answer, deflections, obvious lack of understanding of the modern server/compute environment, lack of understanding of modern security protocol, certain elements of their story changing, outright lying (according to other industry contacts) about not being able to share details with anandtech due to Israeli law, etc.
Ian is careful about not drawing complete conclusions which he shouldn't given his position and lack of expertise in all these areas, but luckily we don't have that standard in a casual tech forum and can call a spade a spade.
Last edited by CAT-THE-FIFTH; 16-03-2018 at 03:08 AM.
Transcript of AT interview with CTS-Labs:
https://www.anandtech.com/show/12536...-with-cts-labs
Wow,they ended the interview early and didn't answer any more questions from AT!!
Commentary and Clarification
All processors and chips have flaws – some are critical, others are simple, some can be fixed through hardware and software. There are security issues and errata in some processors that are several years old.
CTS-Labs’ reasoning for believing that AMD cannot patch within a reasonable period, coming from ‘industry experts’, seems off – almost as if they believe that when they enter a responsible disclosure time-frame, they cannot reveal the vulnerabilities until they are fixed. The response to the question about Meltdown and Spectre, if they would have the same attitude to the fact that the industry had several months before publication for a coordinated effort, means that despite offering a unilateral reasoning for 0-day disclosure, they would not apply it unilaterally but on a case-by-case basis. The language used is clearly not indicative of their actual feeling and policy.
Blaming the lack of CVE numbers on them being ‘new’ to it, yet citing repeatedly many years of security experience and in cyber-security is also in opposition. It may be their first public disclosure, even as individuals, but I find it hard to believe they were not prepared on the CVE front. Using our own experts, it can take hours for a well-known company to be issued a CVE number, or weeks for an unknown entity. Had CTS-Labs approached a big security firm, or AMD, then these could have been issued relatively easily. CTS-Labs stated that they are waiting for CVE numbers to be issued to going to be an interesting outcome, especially if they appear and/or the time of submission is provided.
It seems a bit odd for a company looking into ASMedia related flaws to then turn their focus onto AMD’s secure processor, using the chipset vulnerabilities as a pivot point. ASMedia chips, especially the USB host controllers cited by CTS-Labs, are used on literally tens of millions of Intel-based motherboards around the world, from all the major OEMs. For a large period of time, it was hard to find a system without one. The decision to pivot on newer AMD platforms is a weak argument, the wishy-washy language when discussing projects at the start of the company’s existence, and the abrupt ending to the call when asked to discuss the original customer could be construed (this is conjecture here) that the funding for the product was purposefully directional towards AMD.
The discussion about the understanding of how vulnerabilities can be mitigated certainly piqued David’s interest. The number of things that can be done through microcode, or that are undocumented to third-party chip analysts, means that it came across as highly strange that CTS-Labs were fervent in their believe that AMD could not patch the issue in reasonable time to warrant a longer reasonable disclosure period (one of many arguments used). As seen in recent vulnerabilities and responsible disclosures, chip designers have implemented a number of significant methods to enable/disable/adjust features that were not known to be able to be adjusted, such as resetting a branch predictor. All it takes is for the chip company to say ‘we can do this’ and for it to be implanted, so the use of high-impact language was certainly noted. The confusion between microcode and FPGA in the discussion also raised an eyebrow or three.
When approaching the subject of virtualized environments, the short sharp acceptance that these vulnerabilities were less of an issue in VMs and with cloud providers was quickly overshadowed by the doom and gloom message for if a system was already compromised, even when it was stated that analyst expect 10% market share for EPYC by 2020. It was clear that the definitions of enterprise deployments seemed to differ between AnandTech and CTS-Labs, again partnered with amounts of doom and gloom.
Lastly, the legal argument of not being able to share the details outside of Israel, or only to registered security companies outside of Israel, was an interesting one we were not expecting. This being coupled with the lack of knowledge on the effect of an open disclosure led us to reach out to our legal contacts that are familiar with the situation. This led to the line:
“It’s BS, no restrictions.”
Some of our contacts, and readers with security backgrounds, have privately confirmed that most of this is quite fishy. The combination of the methodology and presentation with a new company that both claims to have experience but can’t do CVE numbers is waving red flags.
Opinion
Going back to the two original questions, here is where I personally stand on the issue:
One What are the vulnerabilities, how bad are they, and what can be done?
One, if the vulnerabilities exist: It is very likely that these vulnerabilities are real. A secondary attack vector that could install monitoring software might be part of a multi-layer attack, but offering a place for indiscriminant monitoring of compromised systems can be seen as an important hole to fix. At this point, the nearest trusted source we have that these vulnerabilities are real is from Alex Ionescu, a Windows Internals Expert who works for CrowdStrike, one of the companies that CTS-Labs says has the full disclosure documents. That is still a stage a bit far from us to warrant a full confirmation. Given that Trail of Bits required 4-5 days to examine CTS-Labs work, I suspect it will take AMD a similar amount of time to do so. If that is the case, AMD might have additional statements either on Friday or Monday, either confirming or rebutting the issues, and discussing future action.
Two Who are CTS-Labs, how come their approach to reasonable responsible disclosure differs to other security firms, how come a number of elements about the disclosure are atypical of a security firm, what is thier financial model, and who are their clients?
Two, the status of CTS-Labs: I’m more than willing to entertain the fact that as a first public high-level disclosure, a security company can be out of step with a few of the usual expected methods of responsible disclosure and presentation. A number of new security companies that want to make a name for themselves have to be bold and brash to get new customers, however we have never quite seen it to this extent – normally the work speaks for itself, of the security company will develop a relationship with the company with the vulnerability and earn its kudos that way. The fact that CTS-Labs went with a polished website (with nine links to download the whitepaper, compared to the Meltdown/Spectre websites that had one), and a PR firm is definitely a different take. The unilateral reasoning for a 0-day/1-day disclosure, followed by a self-rebuttal when presented with a more significant issue, shows elements of inconsistency in their immediate judgement. The lack of CVEs ready to go, despite the employees having many years of experience, as well as experience in the Israeli equivalent of the NSA in Unit 8200, does seem as opposites; an experienced security team would be ready. The swift acceptance that cloud-based systems are vulnerable but then going straight into doom and gloom, despite the limited attack surface in that market, shows that they are focusing on the doom and gloom. The reluctance for CTS-Labs to talk about clients and funding, or previous projects, was perhaps to be expected.
The initial downside of this story coming into the news was the foreboding question of ‘is this how we are going to do security now?’. Despite the actions of CTS and their decision to go with a 24-hour period, after speaking to long-term industry experts at high profile technology companies, a standard 90-180 day pre-disclosure period is still the primary standard that manufacturers would expect security companies to adhere with to actively engage with responsible information and verification. We were told that to go beyond/behind this structure ultimately formulates a level of distrust between the company, the security agency, and potentially the clients, regardless of the capabilities of the security researchers or the severity of the issues found; moreso if the issues are blown out of proportion in relation to their nature and attack surface.
Last edited by CAT-THE-FIFTH; 16-03-2018 at 03:18 AM.
So are "CTS Labs" and any shady affiliates likely to just get away with this or will there be repercussions? Surely some of the short-selling around the time of the release of this article should be investigated?
I think it depends on what AMD wants to hit them for. If these vulnerabilities are proven and re-produce-able then they did not lie and therefore it would be hard to argue in court. I think they could probably look into defamation or libel in some ways. I'm not sure how the financial sector would hit the creators of this and if it is shareholder/competition funded then they're going to be protected up to the hilt to prevent the true sponsor leaking.
I'm not really sure AMD/Courts can actually do much, but I will await someone far more legalese to comment.
Yeah I guess we'll wait to see if these "exploits" are confirmed to be real threats or not but if they do indeed turn out to a waste of time then I'd like to think there are deterrents in place for this kind of blatant market manipulation. What's to stop us forming our own shady testing labs and going all in on some sweet manipulated profits?
We (I presume) don't have a couple of billion with which to short AMD stock. Other than that, depressingly little...
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote