Jan 042018
 

Well, there’s another big and bad security vulnerability; actually there are three. These are known as Meltdown and Spectre (two different Spectres). There are all sorts of bits of information and misinformation out there at the moment and this posting will be no different.

In short, nobody but those involved in the vulnerability research or implementing work-arounds within the wel-known operating systems really knows these vulnerabilities well enough to say anything about them with complete accuracy.

The problem is that both vulnerabilities are exceptionally technical and require detailed knowledge of technicalities that most people are not familiar with. Even people who work in the IT industry.

Having said that I’m not likely to be 100% accurate, let’s dive in …

What Is Vulnerable?

For Meltdown, every modern Intel processor is vulnerable; in fact the only processors from Intel that are not vulnerable are only likely to be encountered in retro-computing. Processors from AMD and ARM are probably not vulnerable, although it is possible to configure at least one AMD processor in such a way that it becomes vulnerable.

It appears that that more processors are likely to be vulnerable to the Spectre vulnerabilities. Exactly what is vulnerable is a bit of work to assess, and people are concentrating on the Meltdown vulnerability as it is more serious (although Spectre is itself serious enough to qualify for a catchy code name).

What Is The Fix?

Replace the processor. But wait until fixed ones have been produced.

However there is a work-around for the Meltdown vulnerability, which is an operating system patch (to fix the operating system) and a firmware patch (to fix the UEFI environment). All of the patches “fix” the problem by removing kernel memory from the user memory map, which stops user processes exploiting Meltdown to read kernel memory.

Unfortunately there is a performance hit with this fix; every time you call the operating system (actually the kernel) to perform something, the memory map needs to be loaded with the kernel maps and re-loaded with the old map when the routine exits.

This “costs” between 5% and 30% when performing system calls. With very modern processors the performance hit will be consistently 5% and with older processors the hit will be consistently 30%.

Having said that, this only happens when calling the operating system kernel, and many applications may very well make relatively few kernel operating system calls in which case the performance hit will be barely noticeable. Nobody is entirely sure what the performance hit will be for real world use, but the best guesses say that most desktop applications will be fine with occasional exceptions (and the web browser is likely to be one); the big performance hit will be on the server.

How Serious Are They?

Meltdown is very serious not only because it allows a user process to read privileged data, but because it allows an attacker to effectively remove a standard attack mitigation which makes many older-style attacks impracticable. Essentially it make older-style attacks practicable again.

Although Spectre is still serious, it may be less so than Meltdown because an attacker needs to be able to control some data that the victim process uses to indulge in some speculative execution. In the case of browsers (for example) this is relatively easy, but in general it is not so easy.

It is also easier to fix and/or protect against on an individual application basis – expect browser patches shortly.

Some Technicalities

Within this section I will attempt to explain some of the technical aspects of the vulnerabilities. By all means skip to the summary if you wish.

The Processor?

Normally security vulnerabilities are found within software – the operating system, or a ‘layered product’ – something installed on top of the operating system such as an application, a helper application, or a run-time environment.

Less often we hear of vulnerabilities that involve hardware in some sense – requiring firmware updates to either the system itself, graphics cards, or network cards.

Similar to firmware updates, it is possible for microcode updates to fix problems with the processor’s instructions.

Unfortunately these vulnerabilities are not found within the processor instructions, but in the way that the processor executes those instructions. And no microcode update can fix this problem (although it is possible to weaken the side-channel attack by making the cache instructions execute in a fixed time).

Essentially the processor hardware needs to be re-designed and new processors released to fix this problem – you need a new processor. The patches for Meltdown and Spectre – both the ones available today, and those available in the future – are strictly speaking workarounds.

The Kernel and Address Space

Meldown specifically targets the kernel and the kernel’s memory. But what is the kernel?

It is a quite common term in the Linux community, but every single mainstream has the same split between kernel mode and user mode. Kernel mode has privileged access to the hardware whereas user mode is prevented from accessing the hardware and indeed the memory of any other user process running. It would be easy to think of this as the operating system and user applications, but that would be technically incorrect.

Whilst the kernel is the operating system, plenty of software that runs in user mode is also part of the operating system. But the over-simplification will do because it contains a useful element of the truth.

Amongst other things the kernel address space contains many secrets that user mode software should not have access to. So why is the kernel mode address space overlaid upon the user mode address space?

One of the jobs that the kernel does when it starts a user mode process, is give to that process a virtual view of the processor’s memory that entirely fills the processor’s memory addressing capability – even if that it is more memory than the machine contains. The reasons for this can be ignored for the moment.

If real memory is allocated to a user process, it can be seen and used by that process and no other.

For performance reasons, the kernel includes it’s own memory within each user process (but protected). It isn’t necessary, but re-programming the memory management unit to map the kernel memory for each system call is slower than not. And after all, memory protection should stop user processes reading kernel memory directly.

That is of course unless memory protection is broken …

Speculative Execution

Computer memory is much slower than modern processors which is why we have cache memory – indeed multiple levels of cache memory. To improve performance processors have long been doing things that come under the umbrella of ‘speculative execution’.

If for example we have the following sample of pseudo-code :-

load variable A from memory location A-in-memory
if A is zero
then
do one thing
else
do another
endif

Because memory is so slow, a processor running this code could stop whilst it is waiting for the memory location to be read. This is how processors of old worked, and is often how processor execution is taught - the next step starts getting really weird.

However it could also execute the code assuming that A will be zero (or not, or even both), so it has the results ready for once the memory has been read. Now there are some obvious limitations to this - the processor can't turn your screen green assuming that A is zero, but it can sometimes get some useful work done.

The problem (with both Meltdown and Spectre) is that speculative execution seems to bypass the various forms of memory protection. Now whilst the speculative results are ignored once the memory is properly read, and the memory protection kicks in, there is a side-channel attack that allows some of the details of the speculative results to be sniffed by an attacker.

 

Summary

  1. Don't panic! These attacks are not currently in use and because of the complexity it will take some time for the attacks to appear in the wild.
  2. Intel processors are vulnerable to Meltdown, and will need a patch to apply a work-around. Apply the patch as soon as it comes out even if it hurts performance.
  3. The performance hit is likely to be significant only on a small set of applications, and in general only significant on a macro-scale - if you run as many servers as Google, you will have to buy more servers soon.
  4. Things are a little more vague with Spectre, but it seems likely that individual applications will need to be patched to remove their vulnerability. Expect more patches.

Tunnel To The Old Town

 

 

Nov 292017
 

If you have not already heard about it, Apple made a mindbogglingly stupid mistake with the latest release of macOS (previously known as OSX), leaving their users open to an incredibly easy exploit that would give anyone full access over an Apple in their hands. Or in some cases, remotely.

The externally visible effect of the vulnerability is that a standard Unix account (root) that was supposed to be disabled was left with a blank password. Apple uses a very common Unix security mechanism that means the root account is unnecessary as an ordinary account (i.e. nobody logs in as root), although the account has to exist so that legitimate privilege escalation works.

As an alternative, Apple uses sudo (and graphical equivalents) so that members of a certain group can run commands as root. Nothing wrong with that.

To keep things safe, Apple disabled the root account and because the account was disabled, left the password blank.

It turns out that the vulnerability was caused by a bug in Apple’s authentication system which resulted in blank passwords being reset and the account enabled. But it is more complicated than that; Apple made a number of mistakes :-

  1. The bug in the authentication system. Of course no software is bug-free, but bugs are still mistakes. Of course because no software is bug-free, it makes sense to take extra precautions to avoid bugs causing a cascade of problems.
  2. The root password should have been set to a random value to prevent access if the account was accidentally enabled.
  3. Apple’s test suite which hopefully they use to verify that new releases don’t contain previously identified bugs should also check for this vulnerability.

Although the precise details don’t matter as it’s the principle of defence in depth.

Hemisphere and Curves

Nov 022017
 

Autocorrect can be annoying when it happens to you, or amusing if it happens to someone else. But one thing that appears when you look at amusing autocorrects on the Internet is that you often find someone saying “it’s the phone” or “the phone is doing it”.

No it isn’t. It’s your fault.

Way back in the mists of time when we didn’t have smartphones and keyboards were big clunky mechanical things (some of us still use them), one of the first bits of IT security advice I ever gave was to read though the emails you are about to send. Whatever means you use to compose a message, there are chances of making a mistake. So what you get in the message you composed may not be what you intended to write.

As a bonus, you get a second chance to review your message to check for “thinkos” (like typos but where your brain comes out with something you didn’t intend).

If you choose to send messages (of whatever kind) without checking they say what you intended, you are responsible for the mistakes.

The Bench

May 172017
 

It may not be very funny, but the funny thing about WannaCrypt is that it is somewhat of a failure! Unless the authors are spectacularly stupid (not entirely impossible incidentally), they have no way to recover their ill-gotten gains. The pile of looted bitcoins they have acquired is fully visible, so any attempt to use those coins will almost certainly result in them being tracked down – they have attracted too much attention.

Which is another aspect of the WannCrypt malware – it has highlighted the vulnerability (MS17-010) and caused a huge vulnerability hunt. Which is causing those who wrote other malware (such as Adylkuzz) to gnash their teeth, because otherwise their malware would have quietly worked away in the background. The malware authors behind Adylkuzz have probably made more money than the WannaCrypt malware authors … and may well get away with their loot too.

Which is why other malware authors “wannacry” – the attention that WannaCrypt has gotten has ruined MS17-010 for them.

May 172017
 

It seems rather strange when you discover it, but Windows Update sometimes lies about what updates have been installed. I am not sure how often this happens, but it does happen from time to time. Which with WannaCrypt rampaging around is somewhat unfortunate.

What seems to happen is that Windows Update gets confused about what patches it has installed – it’s internal database gets corrupt. One possible fix for this is to remove the database :-

net stop wuauserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv
rd /s/q SoftwareDistribution.old

When using Windows 10, you may well have to start (net start wuauserv) Windows Update services before stopping them. Once you have removed the directory, the next time you run Windows Update in the gooey, it will spend some time rebuilding it’s database and hopefully will then pick up the missing updates. No promises but this worked on at least one server that had unacknowledged missing patches.

Of course without a proper vulnerability scanner it may be tricky to determine when Windows is lying about being fully patched. The best bet is to assume it is lying whenever something like WannaCrypt comes along.

The other possibility is to look into something like Autopatcher which is intended for offline updates – you can download the Microsoft updates and use the tool to patch Windows computers from the downloads.

WP2FB Auto Publish Powered By : XYZScripts.com

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close