It would be much easier to hide such a thing in ARM, as ARM usually uses sub-cores for some I/O tasks already. In the end, you have to trust the manufacturer on what they say anyways, unless you put a core you verified yourself on an FPGA.
Of course, there is a huge risk in hiding such a backdoor in hardware. If anybody manages to find a remote exploit and publishes the backdoor access info, this could kill a CPU manufacturer economically.
That is merely a bit more special RF signal analysis engineering and not so much different from other radio-location tasks, although you usually have more data. Calling this "Data Science" is nonsense.
Actually, when their applications leaks data to the client it is not supposed to via the HTTP header, it very much is not "like assembler". It becomes I critical part of the knowledge needed to code this right or at least to understand what an external reviewer is explaining to them after a security review. Knowing about the possible data-paths is critical in order to be competent. Or the other time were I had trouble getting a team to understand how cookie names work (two applications using the same name were accessed over the same proxy and did overwrite each others cookies), because these people had no clue how cookies work and how they are transferred. The list goes on.
No, this is not like asking them to know assembler.
I don't think it is any better on ARM, which is the main alternative. And doing a CPU in an FPGA costs just too much performance-wise. But we will see how things develop. I am not at all above to limit my PC to running games and doing all other stuff on a different machine. In fact, with Win10 being only avoidable for so long, I am in the process of moving all my browsing, email, etc. to a Linux system and that one could be moved to a different architecture pretty easily.
I am aware of this. It is a good start. Now make it work with all ME implementations and the AMD equivalent.
And I really would like that kernel as sort-of BIOS replacement. In all my PCs the Linux kernel does a much better job of finding and initializing the hardware than the BIOS does...
I would like to add that not all web-application developers are incompetent. I have run into the occasional (rare) really competent one, like the one guy I solved a tricky access control problem with last year by just us two locking ourselves into a conference room for an hour and then we had it figured out. I knew the access infrastructure and he really understood his application and the technology used. But for other applications (different teams) in the same application landscape, 6 months or longer even for simple things seems to be normal.
I like the "magic white screen shows up that blows their minds". Nicely describes it.
Well, yes. But what if you do not have senior member that can do it, because the only senior team member is already the only one that can do the more complicated things? That seems to be the standard set-up these days.
Tell me about it. I am a security expert and sometimes do coding for customers. For one large customer, I do cost about 2.5 times per hour than their regular coders. On the other hand, I think that their regular coders are directly more expensive and the time they need to do things (than then suck afterwards) is really impressive. I have seen quotes like $500k just for changing the path in a web-application and placing a proxy in front of it. Incredible.
Well, one additional problem is that selecting a framework is not easy to do and you only find out after having worked with it for some time what it is good at and were it sucks. And long-term support is always dicey. By KISS, if you can reasonably do it without a framework, then do so. Of course, if things get vastly more complicated because of all the things you need to re-invent, that is a different situation.
Ah, yes. "Bouncing Betty" (or "Galloping Gertie"), the Tacoma Narrows Bridge. I saw a picture in my Software Engineering course. Do you have a source of the video that is not YouTube? I should indeed show that to my students as a reminder that they will be engineers and that engineering failure can kill.
My first lecture starts stating that almost every piece of software these days is connected to the Internet in some way. Then it gives a broad overview over the things that can go wrong. I will treat them in-depth later. (Web Application Security is Part II and has its own "first" lecture.) I do buffer overflow including a demo that the students need to replicate themselves, discuss ways this can and cannot be fixed (e.g. NX bit is nice, but does not solve the issue). Next is Taint Checking as a data-path technique. Then data-leakage by behavior, e.g. when you can tell from the error-message that you had guessed a user right. Wherever possible, I add a current example. Final Slide is "human factors", including "Incompetent and unaware of it", The Peter Principle, The Yosemite "bear proof" trashcans that smart bears can still open, but dumb tourists cannot, and finally the "shoot the messenger" problem.
In later lectures, I have all the classics on architecture, design and implementation level, including privilege separation in connection with input validation and normalization and the least privilege principle, fuzzing, password breaking, DoS defense, economic aspects, software maintenance, etc. Unfortunately, space is limited and many things I can only touch on the surface. I would like to make this a 2 semester course, but that is unlike to happen. So I have to select were to dive deep and were to stay on the surface.
It is time to regard the ME (and the AMD equivalent) as what they are: Hardware back-doors. I would like to see more research into breaking into them, disabling them and eventually also reprogramming them. Until the CPU manufacturers hand out full documentation and a reliable way to disable, they must be regarded as malicious attackers in any scenario where security matters.
In the end, this is a good thing however. With a bit of luck, nobody will get away with hidden undocumented hardware in the not so distant future.
I fully agree on all of these. I also teach a software security lecture, and last year one student summarized the purpose as "warn everybody to get an expert and not to do it themselves". Well, at least that one learned something.
As to the last point: This is a real catastrophe in the making. Nobody still understand what they do and their dependencies seem to grow all the time. I now push "does not depend on frameworks" as a sign of quality to customers, wherever possible.
Does not match my experience. Some (few, say 10%) of these people do indeed acquire insight and experience with more time in the field, but most do not seem to. They make the same basic mistakes and have the same defective and incomplete understanding of how thing work, 5 years in, 10 years in and then they move to another field because they have become unemployable in their "specialty".
Web application developers are the lowest-skilled, least educated and least talented people in the IT space. I recently had to explain to some people with supposedly 5 years experience in that space what an HTTP header looks like, because they had no clue. Same for basically every other aspect, like cookie naming, how to make you application able to work behind a proxy (in an enterprise-environment, no less), etc. It is staggering how clueless these people are. All they seem to see is a framework, which they barely understand and then put an application on top that makes all the basic mistakes you can think of. Of course, they eventually remove the mistakes that break the application in the specific target environment for a specific browser, but that is it. Forget about any understanding of the mechanisms they are using or of IT security. Some do not even know what an IP address is or how an URL is composed from components.
So in essence: Developers that are grossly incompetent and management that is grossly incompetent for hiring these people. As we have a lot of "bean-copunter" types in management these days (MBAs and even less competent ones), things will not change anytime soon.
Slashdot Mirror
It would be much easier to hide such a thing in ARM, as ARM usually uses sub-cores for some I/O tasks already.
In the end, you have to trust the manufacturer on what they say anyways, unless you put a core you verified yourself on an FPGA.
Of course, there is a huge risk in hiding such a backdoor in hardware. If anybody manages to find a remote exploit and publishes the backdoor access info, this could kill a CPU manufacturer economically.
That is merely a bit more special RF signal analysis engineering and not so much different from other radio-location tasks, although you usually have more data. Calling this "Data Science" is nonsense.
Sorry, I cannot give you the materials. They would be in German anyways...
Sometimes, I feel like trolling back....
Yes, I know that is not smart.
Actually, when their applications leaks data to the client it is not supposed to via the HTTP header, it very much is not "like assembler". It becomes I critical part of the knowledge needed to code this right or at least to understand what an external reviewer is explaining to them after a security review. Knowing about the possible data-paths is critical in order to be competent. Or the other time were I had trouble getting a team to understand how cookie names work (two applications using the same name were accessed over the same proxy and did overwrite each others cookies), because these people had no clue how cookies work and how they are transferred. The list goes on.
No, this is not like asking them to know assembler.
I don't think it is any better on ARM, which is the main alternative. And doing a CPU in an FPGA costs just too much performance-wise. But we will see how things develop. I am not at all above to limit my PC to running games and doing all other stuff on a different machine. In fact, with Win10 being only avoidable for so long, I am in the process of moving all my browsing, email, etc. to a Linux system and that one could be moved to a different architecture pretty easily.
I am aware of this. It is a good start. Now make it work with all ME implementations and the AMD equivalent.
And I really would like that kernel as sort-of BIOS replacement. In all my PCs the Linux kernel does a much better job of finding and initializing the hardware than the BIOS does...
Indeed. I hope they survive. They have done some really impressive research and shared it.
The classical response of the blind to the one-eyed....
I wish this was only anecdotal. It is not. But as a consultant, I have to protect my customers, regardless of how stupid.
I would like to add that not all web-application developers are incompetent. I have run into the occasional (rare) really competent one, like the one guy I solved a tricky access control problem with last year by just us two locking ourselves into a conference room for an hour and then we had it figured out. I knew the access infrastructure and he really understood his application and the technology used. But for other applications (different teams) in the same application landscape, 6 months or longer even for simple things seems to be normal.
I like the "magic white screen shows up that blows their minds". Nicely describes it.
Well, yes. But what if you do not have senior member that can do it, because the only senior team member is already the only one that can do the more complicated things? That seems to be the standard set-up these days.
Tell me about it. I am a security expert and sometimes do coding for customers. For one large customer, I do cost about 2.5 times per hour than their regular coders. On the other hand, I think that their regular coders are directly more expensive and the time they need to do things (than then suck afterwards) is really impressive. I have seen quotes like $500k just for changing the path in a web-application and placing a proxy in front of it. Incredible.
Well, one additional problem is that selecting a framework is not easy to do and you only find out after having worked with it for some time what it is good at and were it sucks. And long-term support is always dicey. By KISS, if you can reasonably do it without a framework, then do so. Of course, if things get vastly more complicated because of all the things you need to re-invent, that is a different situation.
Well, an 800M Euro firework is kind of impressive on its own.
Ah, yes. "Bouncing Betty" (or "Galloping Gertie"), the Tacoma Narrows Bridge. I saw a picture in my Software Engineering course. Do you have a source of the video that is not YouTube? I should indeed show that to my students as a reminder that they will be engineers and that engineering failure can kill.
My first lecture starts stating that almost every piece of software these days is connected to the Internet in some way. Then it gives a broad overview over the things that can go wrong. I will treat them in-depth later. (Web Application Security is Part II and has its own "first" lecture.) I do buffer overflow including a demo that the students need to replicate themselves, discuss ways this can and cannot be fixed (e.g. NX bit is nice, but does not solve the issue). Next is Taint Checking as a data-path technique. Then data-leakage by behavior, e.g. when you can tell from the error-message that you had guessed a user right. Wherever possible, I add a current example. Final Slide is "human factors", including "Incompetent and unaware of it", The Peter Principle, The Yosemite "bear proof" trashcans that smart bears can still open, but dumb tourists cannot, and finally the "shoot the messenger" problem.
In later lectures, I have all the classics on architecture, design and implementation level, including privilege separation in connection with input validation and normalization and the least privilege principle, fuzzing, password breaking, DoS defense, economic aspects, software maintenance, etc. Unfortunately, space is limited and many things I can only touch on the surface. I would like to make this a 2 semester course, but that is unlike to happen. So I have to select were to dive deep and were to stay on the surface.
It is time to regard the ME (and the AMD equivalent) as what they are: Hardware back-doors. I would like to see more research into breaking into them, disabling them and eventually also reprogramming them. Until the CPU manufacturers hand out full documentation and a reliable way to disable, they must be regarded as malicious attackers in any scenario where security matters.
In the end, this is a good thing however. With a bit of luck, nobody will get away with hidden undocumented hardware in the not so distant future.
Yes, very much so. I see that all the time, especially with large customers.
So, you think that holding technological progress back massively has not hurt basically everybody? You lack understanding.
Who let the clown in?
I fully agree on all of these. I also teach a software security lecture, and last year one student summarized the purpose as "warn everybody to get an expert and not to do it themselves". Well, at least that one learned something.
As to the last point: This is a real catastrophe in the making. Nobody still understand what they do and their dependencies seem to grow all the time. I now push "does not depend on frameworks" as a sign of quality to customers, wherever possible.
Apparently to some, it is not. These may be the people at the core of the problem, though.
Does not match my experience. Some (few, say 10%) of these people do indeed acquire insight and experience with more time in the field, but most do not seem to. They make the same basic mistakes and have the same defective and incomplete understanding of how thing work, 5 years in, 10 years in and then they move to another field because they have become unemployable in their "specialty".
Web application developers are the lowest-skilled, least educated and least talented people in the IT space. I recently had to explain to some people with supposedly 5 years experience in that space what an HTTP header looks like, because they had no clue. Same for basically every other aspect, like cookie naming, how to make you application able to work behind a proxy (in an enterprise-environment, no less), etc. It is staggering how clueless these people are. All they seem to see is a framework, which they barely understand and then put an application on top that makes all the basic mistakes you can think of. Of course, they eventually remove the mistakes that break the application in the specific target environment for a specific browser, but that is it. Forget about any understanding of the mechanisms they are using or of IT security. Some do not even know what an IP address is or how an URL is composed from components.
So in essence: Developers that are grossly incompetent and management that is grossly incompetent for hiring these people. As we have a lot of "bean-copunter" types in management these days (MBAs and even less competent ones), things will not change anytime soon.
Everybody was robbed by him. Some got a fraction of what they were robbed of back...