Ian Cutress de AnandTech y David Kanter de RealWorldTech, se han dedicado a estudiar el mito que ha creado CTS-Labs y las 13 vulnerabilidaes de RyZEN [catalogadas en 4 grupos], y para ello han mantenido una conferencia telefonica con gente de esta empresa dedicada a la seguridad informatica.
La investigacion tiene el objeto de resolver dos cuestiones.
1. ¿Cuáles son las vulnerabilidades, cuán malas son y qué se puede hacer?
2. Quiénes son CTS-Labs, ¿cómo es que su enfoque de revelación responsable razonable difiere de otras empresas de seguridad, cómo es que un número de elementos sobre la divulgación son atípicos de una empresa de seguridad, cuál es su modelo financiero y quiénes son sus clientes?
Al final de la conferencia y tras analizar toda la informacion, estas son las respuestas a las que han llegado.
1. si las vulnerabilidades existen: es muy probable que estas vulnerabilidades sean reales. Un vector de ataque secundario que podría instalar un software de monitoreo podría ser parte de un ataque de varias capas, pero ofrecer un lugar para el monitoreo indiscriminado de los sistemas comprometidos puede verse como un agujero importante para solucionar. En este punto, la fuente de confianza más cercana que tenemos de que estas vulnerabilidades son reales es Alex Ionescu, un experto de Windows Internals que trabaja para CrowdStrike, una de las compañías que según CTS-Labs tiene los documentos de divulgación completos. Esa es todavía una etapa un poco lejos de nosotros para garantizar una confirmación completa. Dado que Trail of Bits requirió 4-5 días para examinar el trabajo de CTS-Labs, sospecho que a AMD le tomará una cantidad de tiempo similar para hacerlo. Si ese es el caso, AMD podría tener declaraciones adicionales el viernes o el lunes, ya sea confirmando o refutando los problemas, y discutiendo acciones futuras.
2. el estado de CTS-Labs: Estoy más que dispuesto a considerar el hecho de que, como primera revelación pública de alto nivel, una compañía de seguridad puede estar fuera de sintonía con algunos de los métodos usuales de divulgación y presentación responsable . Una serie de nuevas compañías de seguridad que quieren hacerse un nombre por sí mismas tienen que ser audaces y temerarias para conseguir nuevos clientes, sin embargo, nunca lo hemos visto hasta este punto; normalmente el trabajo habla por sí mismo, la compañía de seguridad desarrollará un relación con la empresa con la vulnerabilidad y obtener sus felicitaciones de esa manera. El hecho de que CTS-Labs fue con un sitio web pulido (con nueve enlaces para descargar el libro blanco, en comparación con los sitios web Meltdown / Spectre que tenían uno), y una firma de relaciones públicas es definitivamente una toma diferente. El razonamiento unilateral para una divulgación de 0 día / 1 día, seguido de una auto-refutación cuando se presenta un problema más significativo, muestra elementos de inconsistencia en su juicio inmediato. La falta de CVEs listos para funcionar, a pesar de que los empleados tienen muchos años de experiencia, así como también de la experiencia en el equivalente israelí de la NSA en la Unidad 8200, sí parecen opuestos; un equipo de seguridad experimentado estaría listo. La rápida aceptación de que los sistemas basados en la nube no son vulnerables sino que van directamente a la perdición y a la oscuridad, a pesar de la limitada superficie de ataque en ese mercado, muestra que se están enfocando en la oscuridad. La renuencia de CTS-Labs a hablar sobre clientes y financiación, o proyectos anteriores, era tal vez de esperar.
La desventaja inicial de esta historia que llegó a las noticias fue la apremiante pregunta de '¿así es como vamos a hacer la seguridad ahora?'. A pesar de las acciones de CTS y su decisión de irse con un período de 24 horas, después de hablar con expertos de la industria a largo plazo en compañías de tecnología de alto perfil, un estándar previo de 90-180 días antes de la divulgación sigue siendo el estándar primario que los fabricantes esperarían empresas de seguridad a adherirse para participar activamente con la información y verificación responsable. Nos dijeron que ir más allá de esta estructura genera un nivel de desconfianza entre la empresa, la agencia de seguridad y potencialmente los clientes, independientemente de las capacidades de los investigadores de seguridad o la gravedad de los problemas encontrados; más aún si los problemas son desproporcionados en relación con su naturaleza y superficie de ataque.
Una cosa intersante a saber es la existencia de algo llamado 'numeros CVE', los cuales resultan ser unas claves proporcionadas por una organizacion, la cual esta enfocada a registrar todas las vulnerabiliades en el hardware, siendo un estandar en la industira y como sistema que garantiza la seguridad y fiabilidad de todo el hardware en el mundo. Este organismo solo proprociona tales claves o registros a empresas de seguridad certificadas y de confianza, para empresas pequeñas o iniciantes tras una pequeña investigacion de varias semanas el orgaimso aceptara o rechazara la solicitud de proporcionarles dichas claves.
https://cve.mitre.org/cve/identifiers/index.htmlCommon Vulnerabilities and Exposures (CVE):About CVE Entries
CVE Entries (also referred to by the community as "CVE Identifiers," "CVE IDs," "CVE names," "CVE numbers," and "CVEs") are unique, common identifiers for publicly known cybersecurity vulnerabilities. Information is included about the topics below. CVE is a list of entries—each containing an identification number, a
description, and at least one public reference—for publicly known cybersecurity vulnerabilities.
CVE Entries are used in numerous cybersecurity products and services from around the world,
including the U.S. National Vulnerability Database (NVD).
Pues resulta que CTS-Labs no hizo las peticiones para tener estas claves CVE, cosa curiosa porque si contara con la ayuda de AMD u otra emprsa grande o importante tomaria solo dias el poder contar con estas claves,, o si hubieran decidido hacerlo por su cuenta, es una empresa de hace un año de vida, asi que habiendo hecho la solicitud no le hubiera tomado mas que semanas.
Curioso, ¿verdad?, como una empresa que encuentra tantas vulneraciones en un producto y lo hace publico inmediatamente no cuente con el minimo de credenciales, como serian esas claves o apoyo CVE. Como sea, estas son las conclusiones finales.
Comentario y Aclaración, Ian Cutress de AnandTech
Todos los procesadores y chips tienen fallas: algunos son críticos, otros son simples, otros pueden repararse mediante hardware y software. Hay problemas de seguridad y erratas en algunos procesadores que tienen varios años.
El razonamiento de CTS-Labs para creer que AMD no puede parchar dentro de un período razonable, proveniente de "expertos de la industria", parece inactivo, casi como si creyeran que cuando ingresan a un marco de tiempo de revelación responsable, no pueden revelar las vulnerabilidades hasta que estén fijo. La respuesta a la pregunta sobre Meltdown y Spectre, si tuvieran la misma actitud ante el hecho de que la industria tenía varios meses antes de su publicación para un esfuerzo coordinado, significa que a pesar de ofrecer un razonamiento unilateral para la divulgación de 0 días, no aplicarían de manera unilateral, pero caso por caso. El lenguaje utilizado claramente no es indicativo de su sentimiento y política reales.
Culpar a la falta de números CVE de que sean 'nuevos' para él, sin embargo, citar repetidamente muchos años de experiencia en seguridad y en ciberseguridad también está en oposición. Puede ser su primera divulgación pública, incluso como individuos, pero me resulta difícil creer que no estuvieran preparados en el frente de CVE. Usando nuestros propios expertos, puede tomar horas para que una empresa conocida reciba un número CVE, o semanas para una entidad desconocida. Si CTS-Labs se hubiera acercado a una gran empresa de seguridad, o AMD, entonces estos podrían haber sido emitidos con relativa facilidad. CTS-Labs declaró que están esperando que se emitan los números CVE para que sea un resultado interesante, especialmente si aparecen y / o se proporciona el momento del envío.
Parece un poco extraño para una compañía que investiga las fallas relacionadas con ASMedia para luego enfocarse en el procesador seguro de AMD, usando las vulnerabilidades del chipset como un punto de pivote. Los chips ASMedia, especialmente los controladores de host USB citados por CTS-Labs, se utilizan en literalmente decenas de millones de placas base basadas en Intel en todo el mundo, de todos los OEM principales. Durante un largo período de tiempo, fue difícil encontrar un sistema sin uno. La decisión de pivotar en plataformas AMD más nuevas es un argumento débil, el lenguaje flojo cuando se discuten los proyectos al comienzo de la existencia de la empresa, y el abrupto final de la llamada cuando se le preguntó sobre el cliente original podría interpretarse (esto es conjetura aquí) que la financiación del producto fue deliberadamente direccional hacia AMD.
La discusión sobre la comprensión de cómo se pueden mitigar las vulnerabilidades despertó sin duda el interés de David. La cantidad de cosas que se pueden hacer a través de microcódigos, o que no están documentadas a analistas de chips de terceros, significa que resultó muy extraño que CTS-Labs fuera ferviente en su creencia de que AMD no podría parchar el problema en un tiempo razonable para garantiza un período de divulgación razonable más largo (uno de los muchos argumentos utilizados). Como se ha visto en vulnerabilidades recientes y divulgaciones responsables, los diseñadores de chips han implementado una serie de métodos importantes para habilitar / deshabilitar / ajustar características que no se sabía que podían ajustarse, como restablecer un predictor de bifurcación. Todo lo que se necesita es que la empresa de chips diga 'podemos hacer esto' y que se implante, por lo que ciertamente se observó el uso de lenguaje de alto impacto. La confusión entre microcódigo y FPGA en la discusión también levantó una ceja o tres.
Al abordar el tema de los entornos virtualizados, la breve y aguda aceptación de que estas vulnerabilidades eran un problema menor en las VM y con los proveedores de la nube se vio ensombrecida rápidamente por el mensaje de fatalidad si un sistema ya estaba comprometido, incluso cuando se dijo que el analista se espera una cuota de mercado del 10% para EPYC en 2020. Estaba claro que las definiciones de implementaciones empresariales parecían diferir entre AnandTech y CTS-Labs, una vez más asociadas con cantidades de pesimismo.
Por último, el argumento legal de no poder compartir los detalles fuera de Israel, o solo a compañías de seguridad registradas fuera de Israel, fue uno interesante que no esperábamos. Esto, junto con la falta de conocimiento sobre el efecto de una divulgación abierta nos llevó a llegar a nuestros contactos legales que están familiarizados con la situación. Esto llevó a la línea:
"Es BS, sin restricciones".
Algunos de nuestros contactos y lectores con antecedentes de seguridad han confirmado en privado que la mayor parte de esto es bastante sospechoso. La combinación de la metodología y la presentación con una nueva compañía que afirma tener experiencia pero no puede hacer números CVE está ondeando banderas rojas.
https://www.anandtech.com/show/12536/ou ... h-cts-labsOur Interesting Call with CTS-Labsby Ian Cutress
In light of the recent announcement of potential vulnerabilities in Ryzen processors, two stories have emerged. Firstly, that AMD processors could have secondary vulnerabilities in the secure processor and ASMedia chipsets. The second story is behind the company that released the report, CTS-Labs, the approach they have about this disclosure, and the background of this previously unknown security focused outfit – and their intentions as well as their corporate structure. Depending on the angle you take in the technology industry, either as a security expert, a company, the press, or a consumer, one of these stories should interest you.
To make it clear, the two stories boil down to these questions:
-- One What are the vulnerabilities, how bad are they, and what can be done?
-- 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?
In our analysis of the initial announcement, we took time to look at what information we had on the flaws, as well as identifying the number of key features about CTS-Labs that did not fit our standard view of a responsible disclosure as well as a few points on Twitter that did not seem to add up. Since then, we have approached a number of experts in the field, a number of companies involved, and attempted to drill down into the parts of the story that are not so completely obvious. I must thank the readers that reached out to me over email and through Twitter that have helped immensely in getting to the bottom of what we are dealing with.
On the back of this, CTS-Labs has been performing a number of press interviews, leading to articles such as this at our sister site, Tom’s Hardware. CTS reached out to us as well, however a number of factors led to delaying the call. Eventually we found a time to suit everyone. It was confirmed in advance that everyone was happy the call was recorded for transcription purposes.
Joining me on the call was David Kanter, a long-time friend of AnandTech, semiconductor industry consultant, and owner of Real World Technologies. From CTS-Labs, we were speaking with Ido Li On, CEO, and Yaron Luk-Zilberman, CFO.
The text here was transcribed from the recorded call. Some superfluous/irrelevant commentary has been omitted, with the wording tidied a little to be readable.
This text is being provided as-is, with minor commentary at the end. There is a substantial amount of interesting detail to pick through. We try to tackle both of the sides of the story in our questioning.
IC: Who are CTS-Labs, and how did the company start? What are the backgrounds of the employees?¨YLZ: We are three co-founders, graduates of a unit called 8200 in Israel, a technological unit of intelligence. We have a background in security, and two of the co-founders have spent most of their careers in cyber-security and working as consultants for the industry performing security audits for financial institutions and defense organizations and so on. My background is in the financial industry, but I also have a technological background as well.
We came together in the beginning of 2017 to start this company, whose focus was to be in hardware in cyber security. As you guys probably know, this is frontier/niche now that most of the low-hanging fruit in software has been picked up. So this is where the game is moving, we think at least. The goal of the company is to provide security audits, and to deliver reports to our clients on the security of those points.
This is our first major publication. Mostly we do not go public with our results, we just deliver our results to our customers. I should say very importantly that we never deliver the vulnerabilities themselves that we find, or the flaws, to a customer to whom the product does not belong. In other words, if you come to us with a request for an audit of your own, we will give you the code and the proof-of-concepts, but if you want us to audit someone else’s product, even as a consumer of a product or a competitor’s product, or a financial institution, we will not give you the actual code – we will only describe to you the flaw that we find.
This is our business model. This time around in this project, we started with ASMedia, and as you probably know the story moved to AMD as they imported the ASMedia technology into their chipset. Having studied one we started studying the other. This became a very large and important project so we decided we were going to go public with the report. That is what has brought is here.
IC: You said that you do not provide flaws to companies that are not the manufacturer of what you are testing. Does that mean that your initial ASMedia research was done with ASMedia as a customer?ILO: No. So we can audit a product that the manufacturer of the product orders from us, or that somebody else such as a consumer or a third interested party audits from us and then we will provide the part of the description about the vulnerabilities much like our whitepaper but without the technical details to actually implement the exploit.
Actually ASMedia was a test project, as we’re engaged in many projects, and we were looking into their equipment and that’s how it started.
IC: Have you, either professionally or as a hobby, published exploits before?ILO: No we have not. That being said, we have been working in this industry for a very long time as we have done security audits for companies, found vulnerabilities, and given that information to the companies as part of consultancy agreements but we have never actually went public with any of those vulnerabilities.
IC: What response have you had from AMD?ILO: We got the email today to say they were looking into it.
DK: If you are not providing Proof of Concept (PoC) to a customer, or technical details of an exploit, with a way to reproduce it, how are you validating your findings?
YLZ: After we do our validation internally, we take a third party validator to look into our findings. In this case it was Trail of Bits, if you are familiar with them. We gave them full code, full proof of concept with instructions to execute, and they have verified every single claim that we have provided to them. They have gone public with this as well.
In addition to that, In this case we also sent our code to AMD, and then Microsoft, HP, and Dell, the integrators and also domestic and some other security partners. So they have all the findings. We decided to not make them public. The reason here is because we believe it will take many many months for the company, even under ideal circumstances, to come out with a patch. So if we wanted inform consumers about the risks that they have on the product, we just couldn’t afford in our minds to not make the details public.
DK: Even when the security team has a good relationship with a company who has a product with a potential vulnerability, simply verifying a security a hole can take a couple of days at least. For example, with the code provided with Spectre, a security focused outsider could look at the code and make educated guesses within a few minutes to the validity of the claim.
ILO: What we’ve done is this. We have found thirteen vulnerabilities, and we wrote a technical write up on each one of those vulnerabilities with code snippets how they work exactly. We have also produced working PoC exploits for each one of the vulnerabilities so you can actually exploit each one of them. And we have also produced very detailed tutorials on how to run the exploits on test hardware step-by-step to get all the results that we have been able to produce here in the lab. We documented it so well that when we gave it to Trail of Bits, they took it, and ran the procedures by themselves without talking to us and reproduced every one of the results.
We took this package of documents, procedures, and exploits, and we sent it to AMD and other security process that took Trail of Bits about 4-5 days to complete, so I am very certain that they will be able to reproduce this. Also we gave them a list of exactly what hardware to buy and instructions with all the latest BIOS updates and everything.
YLZ: We faced the problems – how do we make a third party validator not just sit there and say ‘this thing works’ but actually do it themselves without us contacting them. We had to write a details manual, a step-by-step kind of thing. So we gave it to them, and Trail of Bits came back to us in five days. I think that the guys we sent it to are definitely able to do it within that time frame
IC: Can you confirm that money changes hands with Trail of Bits?(This was publicly confirmed by Dan Guido earlier, stating that they were expecting to look at one test out of curiosity, but 13 came through so they invoiced CTS for the work. Reuters reports that a $16000 payment was made as ToB’s verification fee for third-party vulnerability checking)
YLZ: I would rather not make any comments about money transactions and things of that nature. You are free to ask Trail of Bits.
IC: The standard procedure for vulnerability disclosure is to have a CVE filing and a Mitre numbers. We have seen in the public disclosures, even 0-day and 1-day public disclosures, have relevant CVE IDs. Can you describe why you haven’t in this case?ILO: We have submitted everything we have to US Cert and we are still waiting to hear back from them.
IC: Can you elaborate as to why you did not wait for those numbers to come through before going live?ILO: It’s our first time around. We haven’t – I guess we should have – this really is our first rodeo.
IC: Have you been I contact with ARM or Trustonic about some of these details?ILO: We have not, and to be honest with you I don’t really think it is their problem. So AMD uses Trustonic t-Base as the base for their firmware on Ryzen processors. But they have built quite a bit of code on top of it and in that code are security vulnerabilities that don’t have much to do with Trustonic t-Base. So we really don’t have anything to say about T-Base.
IC: As some of these attacks go through TrustZone, an Arm Cortex A5, and the ASMedia chipsets, can you speak about other products with these features can also be affected?ILO: I think that the vulnerabilities found are very much … Actually let us split this up between the processor and the chipset as these are very different.
For the secure processor, AMD built quite a thick layer on Trustonic t-Base. They added many features and they also added a lot of features that break the isolation between process running on top of t-Base. So there are a bunch of vulnerabilities there that are not from Trustonic. In that respect we have no reason to believe that we would find these issues on any other product that is not AMDs.
Regarding the chipset, there you actually have vulnerabilities that affect a range of products. Because as we explained earlier, we just looked first at AMD by looking at ASMedia chips. Specifically we were looking into several lines of chips, one of them is the USB host controller from ASMedia. We’re talking about ASM1042, ASM1142, and the recently released ASM1143. These are USB host controllers that you put on the motherboard and they connect on one side with PCIe and on the other side they give you some USB ports.
What we found are these backdoors that we have been describing that come built into the chips – there are two sets of backdoors, hardware backdoors and software backdoors, and we implemented clients for those backdoors. The client works on AMD Ryzen machines but it also works on any machine that has these ASMedia chipsets and so quite a few motherboards and other PCs are affected by these vulnerabilities as well. If you search online for motherboard drivers, such as the ASUS website, and download ASMedia drivers for your motherboard, then those motherboards are likely vulnerable to the same issues as you would find on the AMD chipset. We have verified this on at least six vendor motherboards, mostly the Taiwanese manufacturers. So yeah, those products are affected.
IC: On the website, CTS-Labs states that the 0-day/1-day way of public disclosure is better than the 90-day responsible disclosure period commonly practiced in the security industry. Do you have any evidence to say that the paradigm you are pursuing with this disclosure is any better?YLZ: I think there are pros and cons to both methods. I don’t think that it is a simple question. I think that the advantage of the 30 to 90 days of course is that it provides an opportunity for the vendor to consider the problem, comment on the problem, and provide potential mitigations against it. This is not lost on us.
On the other hand, I think that it also gives the vendors a lot of control on how it wants to address these vulnerabilities and they can first deal with the problem then come out with their own PR about the problem, I’m speaking generally and not about AMD in particular here, and in general they attempt to minimize the significance. If the problem is indicative of a widespread issue, as is the case with the AMD processors, then the company will company probably would want to minimize it and to play it down.
The second problem is that if mitigations are not available in the relevant timespan, this paradigm does not make much sense. You know we were talking to experts about the potential threat to these issues, and some of them are in the logic segment, ASICs, and so there is no obvious direct patch that can be developed for a workaround. This may or may not be available. Then the other one requires issuing a patch in the firmware and then going through the QA process, and typically when it comes to processors, QA is a multi-month process.
I estimate it will be many many months before AMD is able to patch these things. If we had said to them, let’s say, ‘you guys have 30 days/90 days to do this’ I don’t think it would matter very much and it would still be irresponsible on our part to come out after the period and release the vulnerabilities into the open.
So basically the choice that we were facing in this case was either we not tell the public and let the company fix it possibly and only then give it to the public and disclose, and in this circumstance we would have to wait, in our estimate, as much as a year, meanwhile everyone is using the flawed product. Or alternatively we never disclose the vulnerabilities, give it to the company, and then disclose at the same time we are giving it to the company so that the customers are aware of the risks of those products and can decide whether to buy and use them, and so on.
In this case we decided that the second option is the more responsible one, but I would say that in every case that this is the better method. But that is my opinion. Maybe Ilia (CTO) has a slightly different take on that. But these are my concerns.
IC: Would it be fair to say that you felt that AMD would not be able to mitigate these issues within a reasonable time frame, therefore you went ahead and made them public?YLZ: I think that is a very fair statement. I would add that we saw that it was big enough of an issue for the consumer had the right to know about them.
IC: Say, for example, CTS-Labs were in charge of finding Meltdown and Spectre, you would have also followed the same path of logic?YLZ: I think that it would have depended on the circumstances of how we found it, how exploitable it was, how reproducible it was. I am not sure it would be the case. Every situation I think is specific.
DK: How are you absolutely sure that these issues cannot already be rectified in hardware? There are plenty of external chip designers will not be able to tell you with any degree of certainty what can or cannot be rectified through microcode or through patches, though undocumented register flips etc. Who were the chip design experts that you spoke to, and how confident are you that their assessment was correct?
ILO: Let us start by saying that everything we have said are our own estimates based on talks that we have had with people in the semiconductor industry with chip designers and so forth. But these are estimates. We cannot say for certain how long it will take them to patch it or to find a workaround, or if a workaround is possible. I know exactly what you are talking about, that those chips could have undocumented features, and if you flip a bit in a register to enable some hidden feature or something that the engineers left behind on the design, that can help you to turn certain parts of the chip on and off. Maybe you can do that and those registers are very often than not very well documented even within the company itself. I know about this stuff, and everything that I am doing is our own estimates, it may be incorrect, we don’t really know or understand [trails off and doesn’t finish sentence]. Yeah.
In any case, the first thing I can say about this is that ASMedia produces ASICs. So I am fairly certain, based on everything we have read and the research we have done, that this is not an FPGA chip so they can’t just patch it with FPGA updates. I do not know if they have hidden features that would enable them to disable those features and I guess it is up to them to tell us.
YLZ: I think that it is up to them to announce what kind of workaround is available and how costly it will be in terms of disabling features and in terms of performance or whatnot. I think that as you have a hardware level flaw then it is a serious issue.
Regarding how long it would take, we have spoken to experts involved in the QA process in the semiconductor industry and we received a virtually unanimous response that the QA process is the longest part of the patching process. The patching itself may be simple or difficult but the QA process takes a long time.
In fact the one vulnerability that came out with AMD that was a lower level vulnerability that came out about 3 months ago and I believe they still have not come out with a patch. And now we are talking about 13 of them.
ILO: I want to correct that, they did come out with a patch. It took them over three months. It was announced at the end of September, and the new version of AGESA containing the patch came out mid-January, and you have to go through the process of rolling out the new version of AGESA to different motherboard manufacturers and they have to add to their own QA process for the updates and that process might still be rolling two months after the patch came out. It’s a very long process.
But we can’t say with precision how long it will take AMD to come out with patches but we feel confident that it will take months and not weeks.
IC: How many security researchers did you disclose with before going public?YLZ: You mean the technical details in full? Trail of Bits was the only external party and then afterwards together with the company we disclosed to Microsoft, HP, Dell, Symantec, FireEye, and CrowdStrike. They have the whole she-bang.
IC: Gadi Evron, the CEO of Cymmetria, has started talking on social media with knowledge of the vulnerabilities. Can you confirm you briefed them, or did they get the details from other way?ILO: We are in touch them, but they have not gone through the materials yet. They might decide to do that – we are going to see.
YLZ: They are a collaborating with us, so they have seen quite a bit of the findings, but unlike Trail of Bits they have not got the full information, the step-by-step.
IC: Would there be any circumstance in which you would be willing to share the details of these vulnerabilities and exploits under NDA with us?YLZ: We would love to, but there is one quirk. According to Israel export laws, we cannot share the vulnerabilities with people outside of Israel, unless they are a company that provides mitigations to such vulnerabilities. That is why we chose the list. But look, we are interested in the validation of this – we want people to come out and give their opinion, but we are only limited to that circle of the vendors and the security companies, so that is the limitation there.
IC: Would that also prevent you from publishing them publicly?YLZ: That is an interesting question, I haven’t even thought about that.
ILO: I think that we spoke to our lawyers, and generally, as far as I know because I am not a lawyer, but I don’t think it stops us. That being said we have no intension of publishing publicly because of these vulnerabilities to anyone outside the large security companies that can handle these.
IC: Sure, but on the website you have a table at the bottom that says that if anyone finds mitigations to these vulnerabilities to get in contact but you have not supplied any details. How do you marry the fact that you are requesting mitigations and not providing any detail for anyone to replicate the issues?ILO: We are in touch with two large security vendors right now who have the materials and are looking into the materials and producing mitigations. As soon as they do produce them we will definitely update the website.
YLZ: I would add that we can’t assume that we are the only people who have been looking into those processors and found problems there. So what we are saying is that in addition to ourselves, if anyone has mitigations against them, we are happy to share them with the company and to receive it from individuals.
IC: Even though that not producing the details actively limits who can research the vulnerabilities?YLZ: Yes.
There is nothing that I would love more than to have the validation from the world and you guys and everybody else. If I didn’t think that I would be (a) jeopardizing users because it is a long patching process and (b) violating a couple of laws, but yes that’s the only thing. But now we are sitting here with our fingers crossed that the companies that we gave this to, including AMD, come out with their response and accept or reject but we are confident that all of this works but we would love to hear from them.
IC: It was stated that, and I quote, that ‘this is probably as bad as it gets in the world of security’. These vulnerabilities are secondary attack vectors and require admin level access and they also do not work in virtualized environments (because you can’t update a BIOS or chip firmware from a virtual machine) without having metal access which is typically impossible in a VM environment. What makes these worse than primary level exploits that give admin access?ILO: I think that this is an important question. I will give you my opinion. I think that the idea that this requires local admin privileges that it doesn’t matter in a sense because the vector already has the access to the files. What I think that is particularly bad about this secondary attack is that it lets put malware in hardware, such as the secure processor, which has the highest privileges in the system. You are sitting there and you can get to all memory sectors and so from there you can stay undetected by antiviruses, and if the user reinstalls the operating system or formats the hard-drive you still stay there.
So if you think about attaching that to the routine attack, a primary attack, this thing can let an attacker stay there and conduct espionage and sit there indefinitely. Now put yourself in the shoes of a person who discovers that an attack was using this tool and they need to decide what to do now, so they are basically guessing which machine to throw out. That’s one I think kind of degree of severity.
The other is the lateral movement issue as you probably read in our whitepaper: the idea that you can break the virtualization of where the credentials are stored, where the Windows Credentials are in Windows 10. From this an attacker can move laterally in the network – I think it that it is obvious that one of the major barriers to lateral movement is breaking the distinction between software and hardware. If you think about this not as a private user but as an organization that is facing an attack, this is very scary stuff to think that hackers can have the tools of this kind. This is why I think the language is not hyperbole.
IC: Most enterprise level networks are built upon systems that rely on virtual machines (VMs), or use thin clients to access VMs. In this circumstance no OS has bare metal access due to the hypervisor unless the system is already compromised…ILO: Can I stop you there? That is not correct. That is entirely incorrect. We are talking about companies. You know we have a company here – imagine you had a company with four floors with workstations for employees that run Windows and sometimes you have a domain environment on the network….
IC: Those are desktop systems, I specified enterprise.ILO: Yeah, this is enterprise, this is a company. As I said it has four floors with computers inside. They may be running Ryzen Pro workstations. They may have a Microsoft Windows Domain server, maybe a file server, and what we are talking about here is lateral movement inside corporate networks like this one. This is ABC, this is what happens on TSX all over the world with reports about how Chinese hackers behave when they hack US companies and this is how it looks like.
IC: What do you suppose the market penetration is of Ryzen based corporate work deployments?ILO: Well you know they are trying to push hard into this market right now but my own estimate - I don’t know I haven’t done the market research – but the market penetration is not very high. Hopefully it will stay this way until these issues have been resolved as it puts the network at risk.
YLZ: I think that if you look at the market penetration – I have done more market research on this – and I think that analysts are now estimating that by 2020 that AMD will have 10% worldwide server market share. That is in two years. That is quite a few computers out there.
IC: But that is server market share – based mostly on VM oriented systems.DK: Bare metal access to servers is a different animal. If you take the deployments of Azure, even if you have root privileges, you are still running virtualized. Servers are different to desktops.
ILO: Regarding servers, the main impact – let us say you are customer of Microsoft Azure that is integrating EPYC servers right now. You have a virtual machine on the server and that is all you have. To be honest with you, in that particular situation the vulnerabilities do not help you very much. However if a server gets compromised and the cloud provider is relying on secure virtualization to segregate customer data by encrypting memory, and someone runs an exploit on your server and breaks into the SP, they could tamper with this mechanism and this mechanism. I think this is one of main reasons to integrate EPYC servers into the data center – it is the feature that EPYC servers offer to cloud features, and that feature can be broken if someone gets access to the secure processor.
YLZ: We’re talking about the cloud specifically, rather than servers in your data center, then the secure processor can be taken over with very high privileges. So I think it is a huge detail.
YLZ: As much as it is a pleasure talking to you we have time for only a few more questions.
IC: Can you describe how you came up with the names for these exploits?YLZ: It was our creativity and fervent imagination.
IC: Did you pre-brief the press before you spoke to AMD?ILO: What do you mean by pre-brief the press?
IC: We noticed that when the information went live, some press were ready to go with relevant stories and must have had the information in advance.ILO: Before our announcement you mean?
IC: Correct.ILO: I would have to check the timing on that and get back to you, I do not know off the top of my head.
DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?
ILO: I definitely am not going to comment on our customers.
DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.
ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.
[End of Call]
This call took place at 1:30pm ET on 3/14. After the call, we sent a series of 15 questions to CTS-Labs at 6:52pm ET on the same day. As of 7:10pm ET on 3/15, we have not had a response. These questions included elements related to
The use of a PR firm which is non-standard practice for this (and the PR firm were not involved in any way in our call, which is also odd),
Viceroy Research, a company known for shorting stock, and their 25-page blowout report published only three hours after the initial announcement,
And the 2018 SEC listing of the CFO as the President of NineWells Capital, a hedge fund based in New York, that has interests in equity, corporate debt investments, and emphasis on special situations.
If we get answers, we will share these with you.
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 not 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.
.
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
