Posts by Christian Berger

Well Cisco wants to make more money

Obviously you cannot get richt just by selling those (probably already overpriced) products. You can get way more money by selling customers data.

It's not that hard

"Can someone explain how, if this works"

Imagine going do a map service website over https. Your browser will load the tiles from the website over TLS links. In the extreme case of bad HTTP(s) implementations, you create a connection, send your get, and get your tile. Since it's encrypted you don't know what's inside that tile.

However all those tiles are encoded in JPEG (or PNG) which means that their filessizes differ. Encryption doesn't obscure the filesize so you'll be able to see how big that tile was. Since your browser likely loads tiles from roughly the same location, you can use the file sizes to find out what tiles were loaded.

With malware the hope is that the malware will always behave predictibly. For example an initial state always loads a secondary stage that is 123532 octets big, then after 3,21 seconds a terciary stage that's 4235431 octets in size. The idea is that if you 2 downloads 3,21 seconds appart of those sizes in succession, you'll have detectet the malware...

...obviously that's extremely trivial to circumvent, just add padding or other forms of randomness.

This is not a new attack for encryption, but a common thing encryption cannot do by itself.

Re: Yes, there are concepts for that...

"the typical required level of effort"

We are talking about software here, not locks. You only need to put in the effort once. Compared to the other efforts you need to put in (like writing a CNC-Server, designing protocols, etc) this is only a tiny amount of extra effort, and no extra effort per use. It's just a minor change to a tool.

The "lock" analogy is rather bad here, as with locks you have a few generic tools which require lots of effort per use, with IT security it's usually the other way round, all the effort goes into making those tools, using them is comparatively simple.

Re: Yes, there are concepts for that...

"Problem is, in cyberspace, burglars tend to blog their exploits,"

Actually one of the first things you learn at any decent cyber security course is how to circumvent malware scanners. It's something we teach early on to make sure they understand that those solutions cannot work.

Re: Yes, there are concepts for that...

"Will it rise the difficulty of entry beyond what typical burglars are willing to deal with?"

Well actually probably not, because it's not much effort to randomize your traffic. Essentially it's a few random sleeps here and there and some calls to random() instead of using constant values. It takes maybe 10 minutes to circumvert such a problem, and it'll probably take days for companies like Cisco to catch up.

This is not "one lock" you need to stand 10 minutes in front of, this is 10 minutes for a solution which works globally.

Re: What Annoys Me...

No, first of all the problems are different, it's a class of problems nobody bothered looking for, so obviously you will find them at virtually every processor manufacturer using out of order execution as well as some sort of MMU.

Just like in early cryptography many different people were making the same mistakes.

Re: Not only Chip Makers...

Well languages are essentially created equal, while exploits using this in JS might be less stable, there is no hard reason why it shouldn't be possible. After all, you only need attempts at memory access.

Re: " don't run untrusted code"

"For 99.9% of the planet that could be tricky."

That's actually a very big problem. For years people have believed that you can somehow "sandbox" code, so it won't be able to harm your system, and for years people have warned that this might be an illusion. Now we actually see yet another proof that it was.

Now if we had some decent people at the W3C we would see Javascript being phased out.

This is why FOSS hardware designs...

are actually working on verifying that the designs are correct.

https://media.ccc.de/v/34c3-8768-end-to-end_formal_isa_verification_of_risc-v_processors_with_riscv-formal

Re: Can't we just get rid of UEFI?

Well you can rationalize that "feel".

Essentially the biggest problem in IT is complexity. Complexity means high costs when you develop something, high costs for maintain it, as well as lots of bugs, both security critical or not. Therefore it is wise to avoid it.

On the other hand, changes can mean new features. A wise person would weigh those features against the cost of complexity and choose accordingly. Dumb persons ignore the cost of complexity.

UEFI is a typical example where it does add magnitudes of complexity, while essentially doing exactly the same as the old BIOS. There is very little on the "feature" side, but a lot on the complexity side.

UNIX has lots of features which are the opposite. Features like piping are of only minor complexity cost, but allow the functionality to explode. Just add a tiny bit of code to your software, code you often need anyway, and it can be easily combined with other programs.

Re: Now this would be a great idea...

"ALL cryptography is complex*. There are so many ways to get it wrong in lots of non-obvious ways."

Yes, but putting ASN.1 into it certainly doesn't make it easier.

Re: maybe ... just maybe we need better hardware ?

"I'm not sure I agree. Would this mean that more hardware is out of the control of the user/administrator? Imho, that would be the last thing we need. I don't want more ME type issues. "

No, ME/SecureBoot/etc aren't security features. This would work a lot more differently.

Essentially you'd have something like tagged type architectures where the CPU stores values along with their types. Essentially the CPU would be able to know where memory areas end. Additionally you could add tags like "private, not to be put on the network", and functions that encrypt data could add an "encrypted data" tag to it. That way you could put a filter on your network card to only let out private data that's encrypted. Such filters could even work in hardware.

However the big problem is that you loose all compatibility with existing systems. Considering the number of written from scratch full blown operating systems having been developed in the last 20 years was 0, that's quite some work to do.

Re: Mistrust goes in what direction ?

You misunderstand. Things like Trusted Computing and Code signing are not about you trusting your hardware, but about your hardware not trusting you. After all the only think code signing does is to try to prevent you from running code the hardware vendor didn't allow you to put on your hardware. There is no actual user benefit from it, as any attacker with physical access will also be able to just swap the mainboard or even the whole computer. (company computers typically are identical)

Re: Intel Management Engine Source code

"We don't necessary want to remove it, what we want is to see exactly what it does. A good faith response to the revelations would be for Inter to publish the source code to the ME"

Actually even if we had the full source code, it would still make lots of sense to disable it. After all since it's so powerful, if there is one single unpatched security critical bug your system is toast. It's simply a risk Intel (and other companies) forces upon us. Security is in large part about avoiding unnecessary risks.