Schneier on Security

Clive Robinson • March 30, 2013 8:51 AM

ON Topic 🙂

All sorts of strange man made things turn up in the bellies of various denizens of the deep. And some have been sugested since biblical times as the work of god (jonah and the whale).

Now in certain parts of the world bombs in sea water are not exactly unknown for various reasons, such as training grounds, or dumps (both of which are marked as “no fishing areas” on charts in UK waters). Further some ports have “narrow channels” approaches for larger vessels and during war time these can become “bomb runs” as the ships have little or no option but to sail what is in effect a fixed course and enemy attackers know this.

The odd thing about the “bomb” pictured is it does not look the right shape or size for an aircraft type bomb from WWII or later, during WW1 era they did have hand dropped “trench” bombs dropped from aircraft that were small and streamlined. However difficult as it is to tell it does look more like a mortar or warhead of an early rocket.

Now there is another reason why explosives of various kinds end up in sea water and it’s sometimes called “handgrenade fishing”. Fish tend to congregate around underwater structures (like oil rig legs) and it’s not possible to use a net to fish them. In some parts of the world explosives are cheep and easily available from previous conflicts etc. So it’s not unknown for fishermen to chuck explosives on short fuses over the side of a boat to act like a stun grenade that kills or knocks out very many fish that float quickly to the surface where they can be easily gathered into the boat.

Such fishing was carried out in various parts of Africa in places like Nigeria around oil installations and it did so much damage that the Nigerian Government of the time declared in effect “open season” on fishing vessals within sight of oil platforms. It was not unknown on some instalations to have members of the Nigerian Army with large caliber machine guns who’s job it was to provide “warning shots” in the direction of any boat that aproached the instalation without pre aranged permiission.

When I used to work off shore I used to know one specialised diver reasonably well (he had also worn the green) and he had quite a few pictures of dury riged blocks of explosives etc that he had to go down and remove from around off shore instalations befor other divers could do routien maintanence.

And there is yet another reason for bombs and other munitions to be found on the sea bed often quite close to shore, which is shipwreaks and those that have run aground etc.

Oh and one of special notte for those who enjoy a night out in London or Southend etc. Say for instance you are thinking of going to the “O2 Center” that was the Millennium Dome on the Greenwich peninsula to see a major artist or group. Then have a thought about the SS Richard Montgomery munitions ship that sank in shallow water at the mouth of the Thames estury down stream from there during WWII. Basicaly after draging anchor and running aground and breaking it’s back on the Nore sandbank (a notorious hazard to navigation that was the first place to get a permanent light ship) it started to break up and it’s cargo of munitions was only partly recovered…

The wreck off of Southend (51.46583°N 0.78667°E) which remains visable at all states of the tide still has unexploded munitions aboard well into the kiloton range. If a ship or other large vessal going up the Thames bumped into the wreak potentialy a significant explosion could happen causing watter to be focussed up the estuary mouth into an ever larger wave (one initial estimate has indicated that the actual explosion would cause an initial 1000ft wide fountain of water that would rise to over 10,000ft).

Now depending on who you belive in a worst case it could cause an explosion equivalent to a tactical nuclear bomb. Thus it would for a brief moment make your night out go with a bang, prior to it becoming a total washout as a tsunami style wave swept up the river over whelmed the Thames barrier and wiped the O2 center off the map. Befor continuing to rush into London wiping out much of the river frontage including thhe Palace of Westminster that had survived the initial blast wave etc etc.

Oh and one reason for these predictions of doom is that the wreck is a little down stream from the sight that the current London Mayor “Bonking Borris” Johnston wants to build the new major London airport on a man made island, which is very unpopular with many people and vested interests. So the line you hear is if thiss wreck could do so much damage to London think what would happen if this airport is built it could also take out what would become London’s major airport as well OMG it would be a disaster economicaly for London etc etc.

Whilst the wreck is noticably deteriorating after 70 years the truth is nobody knows what would happen if anything, if the wreck was hit by a vessel or was as has been sugested in movie plot type stories attacked by terrorists. As far as I’m aware only one similar vessel has exploded in UK waters before and that was back in 1967 and no deaths or injuries resulted…

Clive Robinson • March 31, 2013 3:57 PM

OFF Topic :

There has been a slowly increasing trend away from MS IE and paid for AV etc to Firefox and Chrome and freeware AV.

Whilst perhaps not surprising (MS realy did shoot themselves in the foot of IE9 and XP) to some it appears to be a surprise to others,

http://gcn.com/blogs/cybereye/2013/03/do-security-conscious-know-something-we-dont.aspx

Clive Robinson • March 31, 2013 11:19 PM

@ spinach,

What good are anti-* scanners when none of them scan device firmware including router and NIC firmware

The same “what good” could be said for just about any security product, the simple fact is none can give comprehensive cover of all aspects of a system.

The reality is it’s a numbers game, where the odds are now firmly in the favour of the attacker not the defender.

Part of the reason for this is we have been “breeding our attackers, nurturing them and making them strong”. We started with systems that had no security as they were designed not to have any as they were stand alone and security did not feature on the users list of requirments.

So even befor we added networking malware attacks were rife via “sneaker net” vulnerabilities and human engineering. Back then as far as we can remember the attacks were not financialy motivated but status / ego motivated.

And those “sneaker net” attacks still work today only the medium is not five inch floppy disks but USB memory devices. The difference is the malware is not status / ego these days but very much for gain / profit (even Stuxnet was for significant financial gain when you think about it).

We did not have security in MS products provided by MS untill well after Win95 during the intervening time consumers have voted for conveniance over security and Internet banking and other insecure financial services on the Internet started up. Arguably even though MS et al have provided increasing levels of security our OS’s and Applications are comparitivly less secure now, than back when they had no inbuilt security, such is the advancment of the attackers.

The reason for the advancment of the attackers is our slow incremental improvments in security have trained up the attackers. Each success they have had has enabled them to accrue the resources to make more significant attacks and the potenttial rewards and comparitivly low risk has dragged in even larger numbers of attackers, but more importantly the support networks from more traditional crime to launder money etc.

The only reason the levels of attack are not higher is a simple numbers game. Each new attack takes time to develop, deploy and reap the rewards. In such a target rich environment there is only so many targets attackers can deal with in any given time.

What Anti-* software does is narrow the oportunity window to a certain extent by making older more prominent attacks less useful to attackers, untill such time as the security hole is fixed by tthe OS and application vendors. That is Anti-* software is an imperfect “stop gap measure”.

As you will appreciate Anti-* software developers also play a numbers game that to many of them feels like a game of Whack-o-mole. They can only analyse a small fraction of the supposed attacks they get made aware of. Obviously the more prominent the attack the higher it gets on their “to do list” but at best they can only deal with a small percentage of the attacks that get developed (it’s why Flame and Duqu are so old yet only recently exposed, and we only know about them because they are “sexy” “james Bondish” and thus news worthy).

Worse for the Anti-* software developers the attack surface they have to cover gets larger with every new release of software, software update and even security patches from software vendors.

Thus the Anti-* companies have to decide on what they are going to focus on as they know they cannot cover all attack vectors and more importantly how they are going to provide the protection (blacklist, whitelist, tripwire, signiture method etc etc).

The more reputable anti-* companies are telling us they cannot keep up and in some cases openly admit it’s a losing game they are playing (see technical comments around Flame and Duqu). They know the only real solution is to reduce the attack surface, but that is not in any way under their control.

And at the end of the day you, I and everyone else are the problem we don’t want security, we want usability feature and fun with the latest apps etc.

The joke of it is that you don’t have to try very hard to get an increased level of security that will put you over and above the interests of cyber-criminals and even some of the cyber-espionage attackers. This is because in a target rich environment they are almost always going to go for the “low hanging fruit” unless there is a specific reason to do otherwise.

Thus you can make plans accordingly such that if you are or are likely to be “a party of interest” to directed attacks then you can take fairly simple steps (segregation) that will make the attackers take a more direct approach if possible, which takes you out of Cyber-security into the older worlds of human and physical security.

However remember if you are of sufficient interest, then as the cartoon has it they will go for the “$5 wrench” technique. And as Ronald Reagan found out 32years ago to the day, that even US President’s are not bullet proof and security is not absolute just probabalistic.

Clive Robinson • April 1, 2013 1:33 AM

@ Josip Medved,

Any truth in “Backdoors Found In Bitlocker FileVault and TrueCrypt?”

That rather depends on what you consider a “backdoor” to be.

As far as we can tell all non trivial software has errors which we call bugs. Some of these will even with the best intentions and current main stream software development methods give rise to security vulnerabilities. If such bugs are discovered and kept quite as “zero days” then they may be regarded as “backdoors”.

Further above software defects in particular applications are protocols and standards. These are known to often have security weaknesses (Wifi’s WEP for instance). The problem with protocol and standards bugs is that they effect many if not all implementations (as we are currently seeing with SSL).

The next problem is how do you know if a bug is accidental or deliberate?

The answer is you don’t nor can you tell retrospectivly when the bug has been found (it’s not science to argue backwards from effect to cause, just opinion).

We know from Stuxnet and friends that there are some very clever people out there who have found methods to break things such as hashes that are unknown in the accademic and public domain. So we don’t know what is actually weak or strong outside of the scope of our limited knowledge. Such knowledge obviously provides an avenue of attack which might be refered to as a “backdoor” (esspecialy if it’s been used to get a flaw into a primary standard).

That said however you don’t need to be clever and have an otherwise unknown flaw to use, a fairly switched on developer with a little knowledge they can find on the Internet will realise there are many was of “accidently” causing bugs to your advantage if you wish to put in a back door capability.

For instance do you know how your memory allocator works in your favourit development language implementation?

If I create a buffer with a memory allocator and then use it to decrypt a key from a protected key ring what happens when I free the buffer?

What happens if I then create another buffer of the same size using the memory allocator?

Well in some cases you get the decrypted key back because it was never overwritten at any point and the memory allocator hands out the first chunk of memory it finds on it’s free list that is large enough for the buffer, which in many cases just happens to be the most recently freed bit of memory…

As I know from experiance such tricks have sailed through code review processes and most other main stream development processes at full speed and nobody noticed. And likewise sailed all the way through software testing and eventually became what these days would be signed release code (it’s why I have no faith in code signing as anything other than a way to mark release code as released).

And that’s the problem, irrespective of if the bug is accidental or deliberate it can make it all the way through the development process un noticed.

It’s worse with protocols and standards. Take AES for instance the actual algorithm is belived to be secure if implemented correctly. But thereby hangs a problem what do you mean by correctly?

One of the design criteria for the AES competition was “speed of implementation” which ment that the example code posted freely for use as part of the competiton rules was optimized for speed not security. And not unexpectedly was full of time based side channels leaking information about the key on modern processors with cache memory.

Now the NSA who were NIST’s technical advisors must have been fully aware of the timing side channel issue, and the effect of making the speed optomised AES code freely available.

But did the “Never Say Anything” organisation advise NIST of this? No not that we are aware of. It was only later that a proof of concept attack against cache based systems showed how bad the problem is. And guess what there are many many AES implementations out there that are still full of time based covert channels leaking information to those who know how to grab it.

Which shows up two problems, firstly recognising there is in effect an unknown security flaw, and secondly getting rid of all the legacy code that contains the flaw.

Right now we are seeing this with SSL it’s basicaly broken in one way or another and has been ever since day one. We are now aware of these weaknesses and as the attacks are new we have a little time to change our SSL implementations. The problem is that even though later versions of the SSL/TLS standards have methods that are currently believed to be secure so change should be easy, nearly everyone still uses the old insecure versions and probably won’t change unless they are forced to in some way (and for various reasons that’s not likely to happen).

So is it possible there is bugs/flaws in these products, the answer is a most definate “yes”, could they be used as backdoors the answer is “probably” are we going to find out well… “only time will tell”.

Clive Robinson • April 1, 2013 5:38 PM

@ Nick P,

…requires a workstation with these minimum specs: Intel Xeon 16-core 3GHz CPU’s, 64GB RAM, 4TB 15,000RPM HD space, four 10Gigabit Ethernet Cards, and NVIDIA Tesla graphics…

Hmm I was looking at a new smart phone that had much more uptodate specs than that.

The only problem was the 24wheeler to carry the battery and 18wheeler to cary the cryogenic cooling plant 🙂