EdX came out of MIT. MIT used to be a strong proponent of OpenCourseware. OpenCourseware classes were both open access *and* open source, so that other instructors could use the material, though admittedly many classes (at least in the computer security domain) never posted videos. EdX courses are open access, but rarely (if ever?) open source. Do you think dropping the requirement to be open source has helped EdX succeed where OpenCourseware failed?
Coursera and EdX primarily source their instructors from college professors. Udacity is more open to bringing in experts from technical fields. In my experience, college professors in the computing fields are often people who chose to get a PhD straight out of college (perhaps because they were mostly interested in research), and as such may not have much (if any) industry experience. Why has EdX chosen a model that focuses limits the ability for technical experts to provide classes?
...assuming you're the kind of person who wants to know how systems work, as opposed to how to run tools.
OST doesn't cater to all topics (yet), because it's volunteer driven. Its primary volunteers thus far have come from a deep system security background. Its assembly, OS/BIOS internals, exploits, and malware curriculum tracks are the most developed, and far deeper than anything you'll (ever) find at SANS, since OST is not commercial and therefore doesn't have to pander to popularity and buzzwords and try to deal with the never-ending churn of trying to put butts in seats.
In the talk he said it was Sandy Bridge and older. Ivy Bridge/Haswell/Broadwell/Sky Lake are not affected. Ivy Bridge was apparently released in 2012 - https://en.wikipedia.org/wiki/... But 1997-2012 is still a decent window of time.
In the talk he also said that it's un-patchable (it's not, the SMI handler can check whether the APIC overlaps the SMM range and change it)
He also said SMM controls every instruction from the boot. It doesn't. Maybe on the crappy Acer netbooks that he said he was using for tests. But on enterprise grade systems from Dell, Lenovo, or HP, they use "protected range registers" to stop SMM from being able to write to the code in the firmware.
It's a good find, but he's got a lot to learn about firmware still.
Grab the Creative Commons licensed slides & videos from some OpenSecurityTraining classes. If you're interested in *fundamentals* then you're going to want to take the x86 classes, and learn to see through the abstraction layers to reality.
I was at VirusBulletin when this was being discussed.
A lot of the other comments are just typical ignorant FUD. Let me tell you exactly what this is: reinventing the wheel.
The speaker described how they had started working on a malware analysis environment back in 2004 and ultimately abandoned it as a failure in 2010. They then *clearly* didn't just look around and see what already existed, but instead just stubbornly decided to press on in making their own.
I was really cringing as the FBI agent described the system to a room full of malware analysis and AV companies, because the system was just so *basic*.
But he said that it received multiple awards within the government and was seen as being super awesome. Just another example of the government being insular and not realizing how far behind industry they are.
For those who think it's a honey pot, it's really not. Not quite anyway. The agent specifically said that the main value to them to make it open is that they *do* want to collect more malware samples. They're starting with LE (who may not be experienced enough to know they can just use one of many other free malware analysis environments, and thus will use the one the FBI hands to them). But then after LE it's a much smaller lift to just open it to everyone, and thus it's sort of a "why not" sort of thing.
It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.
OEM1 releases full source
OEM2 fires all BIOS developers and leeches off OEM1
OEM1 has the privilege of maintaining a BIOS development workforce for the benefit of their competitors
Though maybe that would work as a feint to eventually put competitors at a disadvantage;-)
Also, believe it or not, OEMs and places like AMI, Phoenix, etc do actually try to add features down at the firmware level that their competitors don't have, to differentiate themselves and hopefully get a few more sales. E.g. recall the splashtop OSes that were being pimped as the instant-boot solution to get your browsing quickly a while back. Or I feel like I've seen the ability to check your Outlook from BIOS on HPs:-/
While hobbiests who use custom motherboards are familiar with write protect jumpers, they are going the way of the dodo. They've been all but phased out on OEM laptops, and are going that way on desktops too.
The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus or Chipsec.
Actually most BIOS (legacy or UEFI) have a network stack of some sort in order to support PXE boot. Recall that the PoC BIOS malware Rakshasa (https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf) used the open source SeaBIOS and iPXE network stacks to perform networking from the BIOS.
And here's a talk where some McAfee and Intel folks talked about how keylogging can be done from UEFI thanks to function pointer hooking
(http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html I couldn't find the slides, just video)
And you seem to have missed the point about spammers != state-sponsored attackers who clearly find attacking at this level plenty practical.
(oops, just posted this as an AC. I thought I was logged in)
Your submission, "" was accepted for publication in CCS'13 conference proceedings. You must assign publishing rights to ACM before ACM can proceed to production.
There are several ways you may now assign publishing rights to ACM. You may ask ACM to manage your rights for you (including pursuit of plagiarism and clearance of third-party re-use permissions) by transferring the requested rights to ACM using either the traditional ACM Copyright Transfer Agreement or the ACM Publishing License.
The community has also asked ACM to offer up-front OA fees should authors wish to make their works permanently open access (OA) in the ACM Digital Library.
Should you choose to pay the article fee guaranteeing permanent open access, you may still ask ACM to manage your publishing rights for you by copyright or license. But you will also have a third option: you may choose to manage all rights yourself, by selecting the Permission Form, granting ACM a non-exclusive permission to publish your work.
As of April 2013, ACM is offering authors the option of paying an Article Processing Charge in exchange for permanent OA (open access) for your article in the ACM Digital Library. Should you choose to pay the article fee guaranteeing permanent open access, you may still ask ACM to manage your publishing rights for you (including pursuit of plagiarism and allowing ACM to grant re-use permissions) by transferring the requested rights to ACM using either the traditional ACM Copyright Transfer Agreement or the ACM Publishing License. But you also have a third option: you may choose to manage all rights yourself, by selecting the Permission Form, granting ACM a non-exclusive permission to publish your work.
The Open Access option requires the payment of the APC (Article Processing Charge). The fee is $1,500 if you are not a member of ACM or $1,100 if you or any of your co-authors are ACM members. If you choose the Open Access option, ACM will invoice you separately. If you are not already a member of ACM, consider joining ACM now to take advantage of the member discount rate http://campus.acm.org/public/qj/quickjoin/interim.cfm?promo=PROSOA.
If you do not want to pay the OA fee, you will need to transfer publishing rights to ACM either by using the traditional ACM Copyright Transfer Agreement or choosing the new ACM Publishing License.
Please click on the following link to access and complete the required process of choosing publishing rights for your submission.
Please take a moment to review the form above for errors in the title and author listing. If corrections are needed, please PROCEED to the selected FORM and use the EDIT/tool function located at top of the form and make any necessary changes before submitting the form. The changes will automatically be sent to the PC or proceedings coordinator upon completion. We request that you attend to and complete the form above within 72 hours of the sending of this email.
If the link above does not contain your paper's information, please contact me at your earliest convenience.
Deborah Cotton
ACM Publications
rightsreview@acm.org
Not so much +5 informative as misinformative. Let's begin.
I've studied the entire TPM technical specification. I understand it in minute detail.
I don't doubt you've looked at it. But clearly you've looked at it from the perspective of how you think it impinges on your liberty rather than from the perspective of a security engineer trying to achieve simple properties such as executing code that isn't manipulated by an attacker. That's fine, that's the perspective I expect most slashdotters to be coming at it from. But I'm pretty encouraged by how many people in this thread have pushed back against the normal FUD I expect to see here.
The TPM technical specification is quite explicit that the owner of the computer is FORBIDDEN to ever get his keys
Forbidden from getting them out of the TPM, not forbidden from using them in ways that allow for guaranteeing security properties.If you can just export the key from the TPM onto your normal OS, how would you ever know you were talking to a TPM instead of malware pretending to be a TPM? If you could just ask the TPM to sign something for you with the protected keys, why could the attacker not arbitrarily ask for forged data to be signed?
The owner is forbidden to have his Private Endorsement Key because this key is used to secure the Remote Attestation process against the owner. Remote Attestation is where the chip securely (secure against the owner) securely tracks your hardware and the software you run, and sends that spy-report out to other computers over the internet. If the owner had his Private Endorsement key, these Attestation spy-reports wouldn't be secure against the owner.
An amazingly hyperbolic statement for someone who claims to have read the specs.
1) "The chip" tracks your hardware does it? You understand that the TPM is a completely passive chip waiting for people to come along and send it data, don't you?
2) Same point, again. If you export the EK into the OS, any malware anywhere can forge the attestation state, saying that the system is in a state it is not in. That could mean it's infected when it's not, so it gets reimaged by corporate IT, it can say it's not infected when it is, so the attacker has the run of the network.
3) Only a few large companies are actually using TPMs and remote attestation for things like trusted network connect (just NAC with a TPM-signed configuration), but in reality your FUD-drenched picture of the "spy-reports" (really? wow) being sent out gives the trusted computing folks too much credit. Since no one's using it at the OS level, most all attestation report data is just the BIOS collecting data about itself. And as people showed at BlackHat recently, vendors like Dell don't actually do a very good job of collecting relevant information, collecting just the bare minimum to make bitlocker work - https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf
TPM is just a secure hardware keystore.
It's more than that, but an important part of it is that it's a "secure hardware keystore". Specifically, it is designed to be SECURE AGAINST THE OWNER. The Trusted Platform Module Technical Specification explicitly refers to the owner of the chip as an attack-threat which the chip MUST be secure against.
Citation needed;) I'm sure you're misinterpreting some physical tamper-resistence line. I agree with that person, it's really just a keystore (and a really really slow RC4/SHA1 implementation).
The "Master Keys" are held by the Trusted Computing Group. The crucial individual keys are locked inside the Trusted Computing chips, secured against the owners.
.
It's great that you've read the specs and all, and somehow latched on to the imaginary phrase "secure against the own
Slashdot Mirror
EdX came out of MIT. MIT used to be a strong proponent of OpenCourseware. OpenCourseware classes were both open access *and* open source, so that other instructors could use the material, though admittedly many classes (at least in the computer security domain) never posted videos. EdX courses are open access, but rarely (if ever?) open source. Do you think dropping the requirement to be open source has helped EdX succeed where OpenCourseware failed?
Coursera and EdX primarily source their instructors from college professors. Udacity is more open to bringing in experts from technical fields. In my experience, college professors in the computing fields are often people who chose to get a PhD straight out of college (perhaps because they were mostly interested in research), and as such may not have much (if any) industry experience. Why has EdX chosen a model that focuses limits the ability for technical experts to provide classes?
OST doesn't cater to all topics (yet), because it's volunteer driven. Its primary volunteers thus far have come from a deep system security background. Its assembly, OS/BIOS internals, exploits, and malware curriculum tracks are the most developed, and far deeper than anything you'll (ever) find at SANS, since OST is not commercial and therefore doesn't have to pander to popularity and buzzwords and try to deal with the never-ending churn of trying to put butts in seats.
OpenSecurityTraining.info/Training.html
In the talk he said it was Sandy Bridge and older. Ivy Bridge/Haswell/Broadwell/Sky Lake are not affected. Ivy Bridge was apparently released in 2012 - https://en.wikipedia.org/wiki/... But 1997-2012 is still a decent window of time. In the talk he also said that it's un-patchable (it's not, the SMI handler can check whether the APIC overlaps the SMM range and change it) He also said SMM controls every instruction from the boot. It doesn't. Maybe on the crappy Acer netbooks that he said he was using for tests. But on enterprise grade systems from Dell, Lenovo, or HP, they use "protected range registers" to stop SMM from being able to write to the code in the firmware. It's a good find, but he's got a lot to learn about firmware still.
Maybe now people can have *informed* opinions? Slides here: http://legbacore.com/Research....
Maybe now people can have *informed* opinions? Slides here: http://legbacore.com/Research....
Introduction to Intel x86: Architecture, Assembly, Applications, and Alliteration
Introduction to Intel x86-64: Architecture, Assembly, Applications, and Alliteration
Intermediate Intel x86: Architecture, Assembly, Applications, and Alliteration
With a bonus that you can also learn about ARM assembly in the same class format, and compare and contrast them (what with x86 and ARM being the 2 major architectures which dominate the world's computing devices currently.)
Introduction to ARM
And once you learn x86, how about rather than learning to forward engineer better, how about learning to *reverse* engineer?
Introduction to Reverse Engineering
Reverse Engineering Malware
I was at VirusBulletin when this was being discussed.
A lot of the other comments are just typical ignorant FUD. Let me tell you exactly what this is: reinventing the wheel.
The speaker described how they had started working on a malware analysis environment back in 2004 and ultimately abandoned it as a failure in 2010. They then *clearly* didn't just look around and see what already existed, but instead just stubbornly decided to press on in making their own.
I was really cringing as the FBI agent described the system to a room full of malware analysis and AV companies, because the system was just so *basic*.
But he said that it received multiple awards within the government and was seen as being super awesome. Just another example of the government being insular and not realizing how far behind industry they are.
For those who think it's a honey pot, it's really not. Not quite anyway. The agent specifically said that the main value to them to make it open is that they *do* want to collect more malware samples. They're starting with LE (who may not be experienced enough to know they can just use one of many other free malware analysis environments, and thus will use the one the FBI hands to them). But then after LE it's a much smaller lift to just open it to everyone, and thus it's sort of a "why not" sort of thing.
It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.
OEM1 releases full source
OEM2 fires all BIOS developers and leeches off OEM1
OEM1 has the privilege of maintaining a BIOS development workforce for the benefit of their competitors
Though maybe that would work as a feint to eventually put competitors at a disadvantage ;-)
Also, believe it or not, OEMs and places like AMI, Phoenix, etc do actually try to add features down at the firmware level that their competitors don't have, to differentiate themselves and hopefully get a few more sales. E.g. recall the splashtop OSes that were being pimped as the instant-boot solution to get your browsing quickly a while back. Or I feel like I've seen the ability to check your Outlook from BIOS on HPs :-/
The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus or Chipsec.
Actually most BIOS (legacy or UEFI) have a network stack of some sort in order to support PXE boot. Recall that the PoC BIOS malware Rakshasa (https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf) used the open source SeaBIOS and iPXE network stacks to perform networking from the BIOS. And here's a talk where some McAfee and Intel folks talked about how keylogging can be done from UEFI thanks to function pointer hooking (http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html I couldn't find the slides, just video) And you seem to have missed the point about spammers != state-sponsored attackers who clearly find attacking at this level plenty practical.
(oops, just posted this as an AC. I thought I was logged in) Your submission, "" was accepted for publication in CCS'13 conference proceedings. You must assign publishing rights to ACM before ACM can proceed to production. There are several ways you may now assign publishing rights to ACM. You may ask ACM to manage your rights for you (including pursuit of plagiarism and clearance of third-party re-use permissions) by transferring the requested rights to ACM using either the traditional ACM Copyright Transfer Agreement or the ACM Publishing License. The community has also asked ACM to offer up-front OA fees should authors wish to make their works permanently open access (OA) in the ACM Digital Library. Should you choose to pay the article fee guaranteeing permanent open access, you may still ask ACM to manage your publishing rights for you by copyright or license. But you will also have a third option: you may choose to manage all rights yourself, by selecting the Permission Form, granting ACM a non-exclusive permission to publish your work. As of April 2013, ACM is offering authors the option of paying an Article Processing Charge in exchange for permanent OA (open access) for your article in the ACM Digital Library. Should you choose to pay the article fee guaranteeing permanent open access, you may still ask ACM to manage your publishing rights for you (including pursuit of plagiarism and allowing ACM to grant re-use permissions) by transferring the requested rights to ACM using either the traditional ACM Copyright Transfer Agreement or the ACM Publishing License. But you also have a third option: you may choose to manage all rights yourself, by selecting the Permission Form, granting ACM a non-exclusive permission to publish your work. The Open Access option requires the payment of the APC (Article Processing Charge). The fee is $1,500 if you are not a member of ACM or $1,100 if you or any of your co-authors are ACM members. If you choose the Open Access option, ACM will invoice you separately. If you are not already a member of ACM, consider joining ACM now to take advantage of the member discount rate http://campus.acm.org/public/qj/quickjoin/interim.cfm?promo=PROSOA. If you do not want to pay the OA fee, you will need to transfer publishing rights to ACM either by using the traditional ACM Copyright Transfer Agreement or choosing the new ACM Publishing License. Please click on the following link to access and complete the required process of choosing publishing rights for your submission. Please take a moment to review the form above for errors in the title and author listing. If corrections are needed, please PROCEED to the selected FORM and use the EDIT/tool function located at top of the form and make any necessary changes before submitting the form. The changes will automatically be sent to the PC or proceedings coordinator upon completion. We request that you attend to and complete the form above within 72 hours of the sending of this email. If the link above does not contain your paper's information, please contact me at your earliest convenience. Deborah Cotton ACM Publications rightsreview@acm.org
I've studied the entire TPM technical specification. I understand it in minute detail.
I don't doubt you've looked at it. But clearly you've looked at it from the perspective of how you think it impinges on your liberty rather than from the perspective of a security engineer trying to achieve simple properties such as executing code that isn't manipulated by an attacker. That's fine, that's the perspective I expect most slashdotters to be coming at it from. But I'm pretty encouraged by how many people in this thread have pushed back against the normal FUD I expect to see here.
The TPM technical specification is quite explicit that the owner of the computer is FORBIDDEN to ever get his keys
Forbidden from getting them out of the TPM, not forbidden from using them in ways that allow for guaranteeing security properties.If you can just export the key from the TPM onto your normal OS, how would you ever know you were talking to a TPM instead of malware pretending to be a TPM? If you could just ask the TPM to sign something for you with the protected keys, why could the attacker not arbitrarily ask for forged data to be signed?
The owner is forbidden to have his Private Endorsement Key because this key is used to secure the Remote Attestation process against the owner. Remote Attestation is where the chip securely (secure against the owner) securely tracks your hardware and the software you run, and sends that spy-report out to other computers over the internet. If the owner had his Private Endorsement key, these Attestation spy-reports wouldn't be secure against the owner.
An amazingly hyperbolic statement for someone who claims to have read the specs.
1) "The chip" tracks your hardware does it? You understand that the TPM is a completely passive chip waiting for people to come along and send it data, don't you?
2) Same point, again. If you export the EK into the OS, any malware anywhere can forge the attestation state, saying that the system is in a state it is not in. That could mean it's infected when it's not, so it gets reimaged by corporate IT, it can say it's not infected when it is, so the attacker has the run of the network.
3) Only a few large companies are actually using TPMs and remote attestation for things like trusted network connect (just NAC with a TPM-signed configuration), but in reality your FUD-drenched picture of the "spy-reports" (really? wow) being sent out gives the trusted computing folks too much credit. Since no one's using it at the OS level, most all attestation report data is just the BIOS collecting data about itself. And as people showed at BlackHat recently, vendors like Dell don't actually do a very good job of collecting relevant information, collecting just the bare minimum to make bitlocker work - https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf
TPM is just a secure hardware keystore.
It's more than that, but an important part of it is that it's a "secure hardware keystore". Specifically, it is designed to be SECURE AGAINST THE OWNER. The Trusted Platform Module Technical Specification explicitly refers to the owner of the chip as an attack-threat which the chip MUST be secure against.
Citation needed ;) I'm sure you're misinterpreting some physical tamper-resistence line. I agree with that person, it's really just a keystore (and a really really slow RC4/SHA1 implementation).
The "Master Keys" are held by the Trusted Computing Group. The crucial individual keys are locked inside the Trusted Computing chips, secured against the owners.
.
It's great that you've read the specs and all, and somehow latched on to the imaginary phrase "secure against the own