Contribuez à SecuObs en envoyant des bitcoins ou des dogecoins.
Nouveaux articles (fr): 1pwnthhW21zdnQ5WucjmnF3pk9puT5fDF
Amélioration du site: 1hckU85orcGCm8A9hk67391LCy4ECGJca

Contribute to SecuObs by sending bitcoins or dogecoins.

Chercher :
Newsletter :  


Revues :
- Presse
- Presse FR
- Vidéos
- Twitter
- Secuobs





Sommaires :
- Tendances
- Failles
- Virus
- Concours
- Reportages
- Acteurs
- Outils
- Breves
- Infrastructures
- Livres
- Tutoriels
- Interviews
- Podcasts
- Communiques
- USBsploit
- Commentaires


Revue Presse:
- Tous
- Francophone
- Par mot clé
- Par site
- Le tagwall


Top bi-hebdo:
- Ensemble
- Articles
- Revue
- Videos
- Twitter
- Auteurs


Articles :
- Par mot clé
- Par auteur
- Par organisme
- Le tagwall


Videos :
- Toutes
- Par mot clé
- Par site
- Le tagwall


Twitter :
- Tous
- Par mot clé
- Par compte
- Le tagwall


Commentaires :
- Breves
- Virus
- Failles
- Outils
- Tutoriels
- Tendances
- Acteurs
- Reportages
- Infrastructures
- Interviews
- Concours
- Livres
- Communiques


RSS/XML :
- Articles
- Commentaires
- Revue
- Revue FR
- Videos
- Twitter


RSS SecuObs :
- sécurité
- exploit
- windows
- attaque
- outil
- microsoft


RSS Revue :
- security
- microsoft
- windows
- hacker
- attack
- network


RSS Videos :
- curit
- security
- biomet
- metasploit
- biometric
- cking


RSS Twitter :
- security
- linux
- botnet
- attack
- metasploit
- cisco


RSS Comments :
- Breves
- Virus
- Failles
- Outils
- Tutoriels
- Tendances
- Acteurs
- Reportages
- Infrastructures
- Interviews
- Concours
- Livres
- Communiques


RSS OPML :
- Français
- International











Revue de presse francophone :
- Appaloosa AppDome nouent un partenariat pour accompagner les entreprises dans le déploiement et la protection des applications mobiles
- D-Link offre une avec un routeur VPN sans fil AC
- 19 mai Paris Petit-Déjeuner Coreye Développer son business à l'abri des cyberattaques
- POYNTING PRESENTE LA NOUVELLE ANTENNE OMNI-291, SPECIALE MILIEU MARITIME, CÔTIER ET MILIEU HUMIDE
- Flexera Software Les utilisateurs français de PC progressent dans l'application de correctifs logiciels, mais des défis de tailles subsistent
- Riverbed lance SD-WAN basé sur le cloud
- Fujitsu multi-récompensé VMware lui décerne plusieurs Partner Innovation Awards à l'occasion du Partner Leadership Summit
- Zscaler Private Access sécuriser l'accès à distance en supprimant les risques inhérents aux réseaux privés virtuels
- QNAP annonce la sortie de QTS 4.2.1
- Une enquête réalisée par la société de cyber sécurité F-Secure a décelé des milliers de vulnérabilités graves, potentiellement utilisables par des cyber criminels pour infiltrer l'infrastru
- Trouver le juste équilibre entre une infrastructure dédiée et cloud le dilemme de la distribution numérique
- 3 juin - Fleurance - Cybersécurité Territoires
- Cyber-assurances Seules 40 pourcents des entreprises françaises sont couvertes contre les violations de sécurité et les pertes de données
- Des étudiants de l'ESIEA inventent CheckMyHTTPS un logiciel qui vérifie que vos connexions WEB sécurisées ne sont pas interceptées
- Les produits OmniSwitch d'Alcatel-Lucent Enterprise ALE gagnent en sécurité pour lutter contre les cyber-attaques modernes

Dernier articles de SecuObs :
- DIP, solution de partage d'informations automatisée
- Sqreen, protection applicative intelligente de nouvelle génération
- Renaud Bidou (Deny All): "L'innovation dans le domaine des WAFs s'oriente vers plus de bon sens et d'intelligence, plus de flexibilité et plus d'ergonomie"
- Mises à jour en perspective pour le système Vigik
- Les russes ont-ils pwn le système AEGIS ?
- Le ministère de l'intérieur censure une conférence au Canada
- Saut d'air gap, audit de firmware et (in)sécurité mobile au programme de Cansecwest 2014
- GCHQ: Le JTRIG torpille Anonymous qui torpille le JTRIG (ou pas)
- #FIC2014: Entrée en territoire inconnu
- Le Sénat investit dans les monnaies virtuelles

Revue de presse internationale :
- VEHICLE CYBERSECURITY DOT and Industry Have Efforts Under Way, but DOT Needs to Define Its Role in Responding to a Real-world Attack
- Demand letter served on poll body over disastrous Comeleak breach
- The Minimin Aims To Be The Simplest Theremin
- Hacking group PLATINUM used Windows own patching system against it
- Hacker With Victims in 100 Nations Gets 7 Years in Prison
- HPR2018 How to make Komboucha Tea
- Circuit Bender Artist bends Fresnel Lens for Art
- FBI Director Suggests iPhone Hacking Method May Remain Secret
- 2016 Hack Miami Conference May 13-15, 2016
- 8-bit Video Wall Made From 160 Gaming Keyboards
- In An Era Of Decline, News Sites Can t Afford Poor Web Performance
- BeautifulPeople.com experiences data breach 1m affected
- Swedish Air Space Infringed, Aircraft Not Required
- Why cybercriminals attack healthcare more than any other industry
- Setting the Benchmark in the Network Security Forensics Industry

Annuaire des videos
- FUZZING ON LINE PART THREE
- Official Maltego tutorial 5 Writing your own transforms
- Official Maltego tutorial 6 Integrating with SQL DBs
- Official Maltego tutorial 3 Importing CSVs spreadsheets
- install zeus botnet
- Eloy Magalhaes
- Official Maltego tutorial 1 Google s websites
- Official Maltego tutorial 4 Social Networks
- Blind String SQL Injection
- backdoor linux root from r57 php shell VPS khg crew redc00de
- How To Attaque Pc With Back Track 5 In Arabique
- RSA Todd Schomburg talks about Roundup Ready lines available in 2013
- Nessus Diagnostics Troubleshooting
- Panda Security Vidcast Panda GateDefender Performa Parte 2 de 2
- MultiPyInjector Shellcode Injection

Revue Twitter
- RT @fpalumbo: Cisco consistently leading the way ? buys vCider to boost its distributed cloud vision #CiscoONE
- @mckeay Looks odd... not much to go on (prob some slideshow/vid app under Linux)
- [SuggestedReading] Using the HTML5 Fullscreen API for Phishing Attacks
- RT @BrianHonan: Our problems are not technical but cultural. OWASP top 10 has not changed over the years @joshcorman #RSAC
- RT @mikko: Wow. Apple kernels actually have a function called PE_i_can_has_debugger:
- [Blog Spam] Metasploit and PowerShell payloads
- PinkiePie Strikes Again, Compromises Google Chrome in Pwnium Contest at Hack in the Box: For the second time thi...
- @mikko @fslabs y'all wldn't happen to have lat/long data sets for other botnets, wld you? Doing some research (free/open info rls when done)
- RT @nickhacks: Want to crash a remote host running Snow Leopard? Just use: nmap -P0 -6 --script=targets-ipv6-multicast-mld #wishiwaskidding
- An inexpensive proxy service called is actually a front for #malware distribution -

Mini-Tagwall
Revue de presse : security, microsoft, windows, hacker, attack, network, vulnerability, google, exploit, malware, internet, remote, iphone

+ de mots clés pour la revue de presse

Annuaires des videos : curit, security, biomet, metasploit, biometric, cking, password, windows, botnet, defcon, tutorial, crypt, xploit

+ de mots clés pour les videos

Revue Twitter : security, linux, botnet, attack, metasploit, cisco, defcon, phish, exploit, google, inject, server, firewall

+ de mots clés pour la revue Twitter

Top bi-hebdo des articles de SecuObs
- [Ettercap – Partie 2] Ettercap par l'exemple - Man In the Middle et SSL sniffing
- [Infratech - release] version 0.6 de Bluetooth Stack Smasher
- [IDS Snort Windows – Partie 2] Installation et configuration
- [Infratech - vulnérabilité] Nouvelle version 0.8 de Bluetooth Stack Smasher
- Mises à jour en perspective pour le système Vigik
- USBDumper 2 nouvelle version nouvelles fonctions !
- EFIPW récupère automatiquement le mot de passe BIOS EFI des Macbook Pro avec processeurs Intel
- La sécurité des clés USB mise à mal par USBDUMPER
- Une faille critique de Firefox expose les utilisateurs de Tor Browser Bundle
- Installation sécurisée d'Apache Openssl, Php4, Mysql, Mod_ssl, Mod_rewrite, Mod_perl , Mod_security

Top bi-hebdo de la revue de presse
- StackScrambler and the Tale of a Packet Parsing Bug

Top bi-hebdo de l'annuaire des videos
- DC++ Botnet. How To DDos A Hub With Fake IPs.
- Comment creer un server botnet!!!!(Réseau de pc zombies)
- Defcon 14 Hard Drive Recovery Part 3

Top bi-hebdo de la revue Twitter
- RT @secureideas: I believe that all the XSS flaws announced are fixed in CVS. Will test again tomorrow if so, release 1.4.3. #BASESnort
- Currently, we do not support 100% of the advanced PDF features found in Adobe Reader... At least that's a good idea.
- VPN (google): German Foreign Office Selects Orange Business for Terrestrial Wide: Full
- @DisK0nn3cT Not really, mostly permission issues/info leak...they've had a couple of XSS vulns but nothing direct.
- Swatting phreaker swatted and heading to jail: A 19-year-old American has been sentenced to eleven years in pris..
- RT @fjserna You are not a true hacker if the calc.exe payload is not the scientific one... infosuck.org/0x0035.png

Top des articles les plus commentés
- [Metasploit 2.x – Partie 1] Introduction et présentation
- Microsoft !Exploitable un nouvel outil gratuit pour aider les développeurs à évaluer automatiquement les risques
- Webshag, un outil d'audit de serveur web
- Les navigateurs internet, des mini-systèmes d’exploitation hors de contrôle ?
- Yellowsn0w un utilitaire de déblocage SIM pour le firmware 2.2 des Iphone 3G
- CAINE un Live[CD|USB] pour faciliter la recherche légale de preuves numériques de compromission
- Nessus 4.0 placé sous le signe de la performance, de l'unification et de la personnalisation
- [Renforcement des fonctions de sécurité du noyau Linux – Partie 1] Présentation
- [IDS Snort Windows – Partie 1] Introduction aux IDS et à SNORT
- Origami pour forger, analyser et manipuler des fichiers PDF malicieux

Thoughts on Intel's upcoming Software Guard Extensions Part 2

Si vous voulez bloquer ce service sur vos fils RSS
Si vous voulez nous contacter ou nous proposer un fil RSS

Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

S'abonner au fil RSS global de la revue de presse



Thoughts on Intel's upcoming Software Guard Extensions Part 2

Par The Invisible Things Lab's blog
Le [2013-09-23] à 20:25:46



Présentation : In the first part of this article published a few weeks ago, I have discussed the basics of Intel SGX technology, and also discussed challenges with using SGX for securing desktop systems, specifically focusing on the problem of trusted input and output. In this part we will look at some other aspects of Intel SGX, and we will start with a discussion of how it could be used to create a truly irreversible software. SGX Blackboxing Apps and malware that cannot be reverse engineered A nice feature of Intel SGX is that the processor automatically encrypts the content of SGX-protected memory pages whenever it leaves the processor caches and is stored in DRAM. In other words the code and data used by SGX enclaves never leave the processor in plaintext. This feature, no doubt influenced by the DRM industry, might profoundly change our approach as to who controls our computers really. This is because it will now be easy to create an application, or malware for that matter, that just cannot be reversed engineered in any way. No more IDA, no more debuggers, not even kernel debuggers, could reveal the actual intentions of the EXE file we're about to run. Consider the following scenario, where a user downloads an executable, say blackpill.exe, which in fact logically consists of three parts 1. A 1st stage loader SGX loader which is unencrypted, and which task is to setup an SGX enclave, copy the rest of the code there, specifically the 2nd stage loader, and then start executing the 2nd stage loader... 2. The 2nd stage loader, which starts executing within the enclave, performs remote attestation with an external server and, in case the remote attestation completes successfully, obtains a secret key from the remote server. This code is also delivered in plaintext too. 3. Finally the encrypted blob which can only be decrypted using the key obtained by the 2nd stage loader from the remote server, and which contains the actual logic of the application or malware . We can easily see that there is no way for the user to figure out what the code from the encrypted blob is going to do on her computer. This is because the key will be released by the remote server only if the 2ndstage loader can prove via remote attestation that it indeed executes within a protect SGX enclave and that it is the original unmodified loader code that the application's author created. Should one bit of this loader be modified, or should it be attempted to run outside of an SGX enclave, or within a somehow misconfigured SGX enclave, then the remote attestation wouldfail and the key will not be obtained. And once the key is obtained, it is available only within the SGX enclave. It cannot be found in DRAM or on the memory bus, even if the user had access to expensive DRAM emulators or bus sniffers. And the key cannot also be mishandled by the code that runs in the SGX enclave, because remote attestation also proved that the loader code has not been modified, and the author wrote the loader specifically not to mishandle the key in any way e.g. not to write it out somewhere to unprotected memory, or store on the disk . Now, the loader uses the key to decrypt the payload, and this decrypted payload remains within secure enclave, never leaving it, just like the key. It's data never leaves the enclave either... One little catch is how the key is actually sent to the SGX-protected enclave so that it could not be spoofed in the middle Of course it must be encrypted, but to which key Well, we can have our 2ndstage loader generate a new key pair and send the public key to the remote server the server will then use this public key to send the actual decryption key encrypted with this loader's public key. This is almost good, except for the fact that this scheme is not immune to a classic main in the middle attack. The solution to this is easy, though if I understand correctly the description of the new Quoting and Sealing operations performed by the Quoting Enclave we can include the generated public key hash as part of the data that will be signed and put into the Quote message, so the remote sever can be assured also that the public key originates from the actual code running in the SGX enclave and not from Mallory somewhere in the middle. So, what does the application really do Does it do exactly what has been advertised by its author Or does it also accidentally sniffs some system memory or even reads out disk sectors and sends the gathered data to a remote server, encrypted, of course We cannot know this. And that's quite worrying, I think. One might say that we do accept all the proprietary software blindly anyway after all who fires up IDA to review MS Office before use Or MS Windows Or any other application Probably very few people indeed. But the point is this could be done, and actually some brave souls do that. This could be done even if the author used some advanced form of obfuscation. Can be done, even if taking lots of time. Now, with Intel SGX it suddenly cannot be done anymore. That's quite a revolution, complete change of the rules. We're no longer masters of our little universe the computer system and now somebody else is. Unless there was a way for Certified Antivirus companies to get around SGX protection.... see below for more discussion on this . ...And some good applications of SGX The SGX blackboxing has, however, some good usages too, beyond protecting the Hollywood productions, and making malware un-analyzable... One particularly attractive possibility is the trusted cloud where VMs offered to users could not be eavesdropped or tampered by the cloud provider admins. I wrote about such possibility two years ago, but with Intel SGX this could be done much, much better. This will, of course, require a specially written hypervisor which would be setting up SGX containers for each of the VM, and then the VM could authenticate to the user and prove, via remote attestation, that it is executing inside a protected and properly set SGX enclave. Note how this time we do not require the hypervisor to authenticate to the users we just don't care, if our code correctly attests that it is in a correct SGX, it's all fine. Suddenly Google could no longer collect and process your calendar, email, documents, and medial records Or how about a tor node that could prove to users that it is not backdoored by its own admin and does not keep a log of how connections were routed Or a safe bitcoin web-based wallet It's hard to overestimate how good such a technology might be for bringing privacy to the wide society of users... Assuming, of course, there was no backdoor for the NSA to get around the SGX protection and ruin this all goodness... see below for more discussion on this . New OS and VMM architectures In the paragraph above I mentioned that we will need specially written hypervisors VMMs that will be making use of SGX in order to protect the user's VMs against themselves i.e. against the hypervisor . We could go further and put other components of a VMM into protected SGX enclaves, things that we currently, in Qubes OS, keep in separate Service VMs, such as networking stacks, USB stacks, etc. Remember that Intel SGX provides convenient mechanism to build inter-enclave secure communication channels. We could also take the GUI domain currently this is just Dom0 in Qubes OS and move it into a separate SGX enclave. If only Intel came up with solid protected input and output technologies that would work well with SGX, then this would suddenly make whole lots of sense unlike currently where it is very challenging . What we win this way is that no longer a bug in the hypervisor should be critical, as it would be now a long way for the attacker who compromised the hypervisor to steal any real secret of the user, because there are no secrets in the hypervisor itself. In this setup the two most critical enclaves are 1 the GUI enclave, of course, and 2 the admin enclave, although it is thinkable that the latter could be made reasonably deprivileged in that it might only be allowed to create remove VMs, setup networking and other policies for them, but no longer be able to read and write memory of the VMs Anti Snowden Protection, ASP . And... why use hypervisors Why not use the same approach to compartmentalize ordinary operating systems Well, this could be done, of course, but it would require considerable rewrite of the systems, essentially turning them into microkernels except for the fact that the microkernel would no longer need to be trusted , as well as the applications and drivers, and we know that this will never happen. Again, let me repeat one more time the whole point of using virtualization for security is that it wraps up all the huge APIs of an ordinary OS, like Win32 or POSIX, or OSX, into a virtual machine that itself requires orders of magnitude simpler interface to from the outside world especially true for paravirtualized VMs , and all this without the need to rewrite the applications. Trusting Intel Next Generation of Backdooring We have seen that SGX offers a number of attractive functionality that could potentially make our digital systems more secure and 3rdparty servers more trusted. But does it really The obvious question, especially in the light of recent revelations about NSA backdooring everything and the kitchen sink, is whether Intel will have backdoors allowing privileged entities to bypass SGX protections Traditional CPU backdooring Of course they could, no question about it. But one can say that Intel as well as AMD might have been having backdoors in their processors for a long time, not necessarily in anything related to SGX, TPM, TXT, AMT, etc. Intel could have built backdoors into simple MOV or ADD instructions, in such a way that they would automatically disable ring page protections whenever executed with some magic arguments. I wrote more about this many years ago. The problem with those traditional backdoors is that Intel or a certain agency could be caught using it, and this might have catastrophic consequences for Intel. Just imagine somebody discovered during a forensic analysis of an incident that doing MOV eax, deadbeefMOV ebx, babecafeADD eax, ebx ...causes ring elevation for the next 1000 cycles. All the processors affected would suddenly became equivalents of the old 8086 and would have to be replaced. Quite a marketing nightmare I think, no Next-generation CPU backdooring But as more and more crypto and security mechanisms got delegated from software to the processor, the more likely it becomes for Intel or AMD to insert really plausibly deniable backdoors into processors. Consider e.g. the recent paper on how to plant a backdoor into the Intel's Ivy Bridge's random number generator usable via the new RDRAND instruction . The backdoor reduces the actual entropy of the generator making it feasible to later brute-force any crypto which uses keys generated via the weakened generator. The paper goes into great lengths describing how this backdoor could be injected by a malicious foundry e.g. one in China , behind the Intel's back, which is achieved by implementing the backdoor entirely below the HDL level. The paper takes a classic view on the threat model with Good Americans Intel engineers and the Bad Chinese foundry operators employees . Nevertheless, it should be obvious that Intel could have planted such a backdoor without any effort or challenge described in the paper, because they could do so at any level, not necessarily below HDL. But backdooring an RNG is still something that leaves traces. Even though the backdoored processor can apparently pass all external randomness testes, such as the NIST testsuite, they still might be caught. Perhaps because somebody will buy 1000 processors and will run them for a year and will note down all the numbers generated and then conclude that the distribution is quite not right. Or something like that. Or perhaps because somebody will reverse-engineer the processor and specifically the RNG circuitry and notice some gates are shorted to GND. Or perhaps because somebody at this Bad Chinese foundry will notice that. Let's now get back to Intel SGX -- what is the actual Root of Trust for this technology Of course, the processor, just like for the old ring3 ring0 separation. But for SGX there is additional Root of Trust which is used for remote attestation, and this is the private key s used for signing the Quote Messages. If the signing private key somehow got into the hands of an adversary, the remote attestation breaks down completely. Suddenly the SGX Blackboxed apps and malware can readily be decrypted, disassembled and reverse engineered, because the adversary can now emulate their execution step by step under a debugger and still pass the remote attestation. We might say this is good, as we don't want irreversible malware and apps. But then, suddenly, we also loose our attractive trusted cloud too now there is nothing that could stop the adversary, who has the private signing key, to run our trusted VM outside of SGX, yet still reporting to us that it is SGX-protected. And so, while we believe that our trusted VM should be trusted and unsniffable, and while we devote all our deepest secrets to it, the adversary can read them all like on a plate. And the worst thing is even if somebody took such a processor, disassembled it into pieces, analyzed transitor-by-transitor, recreated HDL, analyzed it all, then still it all would look good. Because the backdoor is... the leaked private key that is now also in the hands of the adversary, and there is no way to prove it by looking at the processor alone. As I understand, the whole idea of having a separate TPM chip, was exactly to make such backdoor-by-leaking-keys more difficult, because, while we're all forced to use Intel or AMD processors today, it is possible that e.g. every country can produce their own TPM, as it's million times less complex than a modern processor. So, perhaps Russia could use their own TPMs, which they might be reasonably sure they use private keys which have not be handed over to the NSA. However, as I mentioned in the first part of this article, sadly, this scheme doesn't work that well. The processor can still cheat the external TPM module. For example, in case of an Intel TXT and TPM the processor can produce incorrect PCR values in response to certain trigger in that case it no longer matters that the TPM is trusted and keys not leaked, because the TPM will sign wrong values. On the other hand we go back now to using traditional backdoors in the processors, whose main disadvantage is that people might got cought using them e.g. somebody analyzed an exploit which turns out to be triggering correct Quote message despite incorrect PCRs . So, perhaps, the idea of separate TPM actually does make some sense after all What about just accidental bugs in Intel products Conspiracy theories aside, what about accidental bugs What are the chances of SGX being really foolproof, at least against those unlucky adversaries who didn't get access to the private signing keys The Intel's processor have become quite a complex beasts these days. And if you also thrown in the Memory Controller Hub, it's unimaginably complex beast. Let's take a quick tour back discussing some spectacular attacks against Intel hardware security mechanisms. I wrote hardware in quotation marks, because really most of these technologies is software, like most of the things in electronics these days. Nevertheless the hardware enforced security does have a special appeal to lots of people, often creating an impression that these must be some ultimate unbreakable technologies.... I think it all started with our exploit against Intel Q35 chipset slides 15 demonstrated back in 2008 which was the first attack allowing to compromise, otherwise hardware-protected, SMM memory on Intel platforms some other attacks against SMM shown before assumed the SMM was not protected, which was the case on many older platforms . This was then shortly followed by another paper from us about attacking Intel Trusted Execution Technology TXT , which found out and exploited a fact that TXT-loaded code was not protected against code running in the SMM mode. We used our previous attack on Q35 against SMM, as well as found a couple of new ones, in order to compromise SMM, plant a backdoor there, and then compromise TXT-loaded code from there. The issue highlighted in the paper has never really been correctly patched. Intel has spent years developing something they called STM, which was supposed to be a thin hypervisor for SMM code sandboxing. I don't know if the Intel STM specification has eventually been made public, and how many bugs it might be introducing on systems using it, or how much inaccurate it might be. In the following years we presented two more devastating attacks against Intel TXT none of which depending on compromised SMM onewhich exploited a subtle bug in the processor SINIT module allowing to misconfigure VT-d protections for TXT-loaded code, and another one exploiting a classic buffer overflow bug also in the processor's SINIT module, allowing this time not only to fully bypass TXT, but also fully bypass Intel Launch Control Policy and hijack SMM several years after our original papers on attacking SMM the old bugs got patched and so this was also attractive as yet another way to compromise SMM for whatever other reason . Invisible Things Lab has also presented first, and as far as I'm aware still the only one, attack on Intel BIOS that allowed to reflash the BIOS despite Intel's strong hardware protection mechanism to allow only digitally signed code to be flashed. We also found outabout secret processor in the chipset used for execution of Intel AMT code and we found a way to inject our custom code into this special AMT environment and have it executed in parallel with the main system, unconstrained by any other entity. This is quite a list of Intel significant security failures, which I think gives something to think about. At the very least that just because something is hardware enforced or hardware protected doesn't mean it is foolproof against software exploits. Because, it should be clearly said, all our exploits mentioned above were pure software attacks. But, to be fair, we have never been able to break Intel core memory protection ring separation, page protection or Intel VT-x. Rafal Wojtczuk has probably came closest with his SYSRET attackin an attempt to break the ring separation, but ultimately the Intel's excuse was that the problem was on the side of the OS developers who didn't notice subtle differences in the behavior of SYSRET between AMD and Intel processors, and didn't make their kernel code defensive enough against Intel processor's odd behavior. We have also demonstrated rather impressive attacks bypassing Intel VT-d, but, again, to be fair, we should mention that the attacks were possible only on those platforms which Intel didn't equip with so called Interrupt Remapping hardware, and that Intel knew that such hardware was indeed needed and was planning it a few years before our attacks were published. So, is Intel SGX gonna be as insecure as Intel TXT, or as secure as Intel VT-x.... The bottom line Intel SGX promises some incredible functionality to create protected execution environments called enclaves within untrusted compromised Operating System. However, for SGX to be of any use on a client OS, it is important that we also have technologies to implement trusted output and input from to the SGX enclave. Intel currently provides little details about the former and openly admits it doesn't have the later. Still, even without trusted input and output technologies, SGX might be very useful in bringing trust to the cloud, by allowing users to create trusted VMs inside untrusted provider infrastructure. However, at the same time, it could allow to create applications and malware that could not be reversed engineered. It's quote ironic that those two applications trusted cloud and irreversible malware are mutually bound together, so that if one wanted to add a backdoor to allow A V industry to be able to analyze SGX-protected malware, then this very same backdoor could be used to weaken the guarantees of the trustworthiness of the user VMs in the cloud. Finally, a problem that is hard to ignore today, in the post-Snowden world, is the ease of backdooring this technology by Intel itself. In fact Intel doesn't need to add anything to their processors all they need to do is to give away the private signing keys used by SGX for remote attestation. This makes for a perfectly deniable backdoor nobody could catch Intel on this, even if the processor was analyzed transistor-by-transistor, HDL line-by-line. As a system architect I would love to have Intel SGX, and I would love to believe it is secure. It would allow to further decompose Qubes OS, specifically get rid of the hypervisor from the TCB, and probably even more. Special thanks to Oded Horowitz for turning my attention towards Intel SGX.

Les mots clés de la revue de presse pour cet article : upcoming



AddThis Social Bookmark Widget



Les derniers articles du site "The Invisible Things Lab's blog" :

- Migrating my blog out of Blogger...
- Qubes R3 Odyssey initial source code release
- Announcing Qubes OS Release 2
- Physical separation vs. Software compartmentalization
- Qubes OS R2 rc2, Debian template, SSLed Wiki, BadUSB, and more...
- Qubes OS R2 rc1 has been released
- Shattering the myths of Windows security
- Qubes R2 Beta 3 has been released
- Windows 7 seamless GUI integration coming to Qubes OS
- Thoughts on Intel's upcoming Software Guard Extensions Part 2




S'abonner au fil RSS global de la revue de presse

Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]



Si vous voulez bloquer ce service sur vos fils RSS :
- avec iptables "iptables -A INPUT -s 88.190.17.190 --dport 80 -j DROP"
- avec ipfw et wipfw "ipfw add deny from 88.190.17.190 to any 80"
- Nous contacter par mail




SecuToolBox :

Mini-Tagwall des articles publiés sur SecuObs :

Mini-Tagwall de l'annuaire video :

Mini-Tagwall des articles de la revue de presse :

Mini-Tagwall des Tweets de la revue Twitter :