Adobe Flash (the browser plug-in) is notorious as a security risk, and the current batch of known exploits does nothing to improve it’s reputation. Sorry Adobe. CVE-2016-1010 is the latest biggie, as it allows remote code execution on all but the very latest plug-in. There’s also CVE-2015-8651, CVE-2015-7645, CVE-2016-0963 and CVE-2016-0993 to worry about.
You should, of course, make sure that you have the latest plugging installed on your browser. Unfortunately the version numbering system varies by platform so I can’t easily tell you which you need.
When looking at multifarious Adobe Flash vulnerabilities in the NIST database I’m always amused to note that it appears to be written in Coldfusion. For the last ten years that’s been Adobe Coldfusion. Oh my!
At very long last, the BBC micro:bit has been released. This is the educational embedded computer designed to inspire kids to learn about real programming. A small board with a CPU, Bluetooth, two switches and some LEDs it’s ideal for… Well what? Obvious comparisons will be made with the established but overcomplicated Raspberry Pi.
The plan is to send these out to year 7 students over the Easter holiday. I’m involved in computer science education, but I can’t even buy one (although I can use the simulator). Quite how these will be received when they turn up during Summer term remains to be seen, but I suspect eBay will feature in getting them to those who are interested in this kind of thing.
Unfortunately, from it’s inception in 2012, those of us who have been watching events unfold have a one-word verdict in common: Fiasco.
I’ll let you know more if I actually get to see one.
A bug has been found and fixed in the FreeBSD kernel that would allow someone with malicious intent to crash a running system. It’d be difficult to achieve unless the attacker had console access. However it’s been patched for all supported systems. See here for all the details (which I won’t repeat).
The sysarch() system call is used to get/set processor-specific stuff. You’re not supposed to call it directly; you’re supposed to call a processor-specific library if you want to do things like that, but you still can call it if you want to. On processors that support memory segments, such as i386, there is a Local Descriptor Table (LDT) to manage them if you want to mess with specific stuff like that. However, for security reasons, you can only modify the LDT using the sysarch() call, which checks what you’re trying to do and prevents applications from doing anything crazy.
Unfortunately the AMD64 implementation of the code gets the checking wrong. If you use a signed integer it’s always going to be less than another unsigned value, and when it compares the two parameters to make sure that one is less than the other it passes when it shouldn’t, and the rogue parameter causes it to go funky-deux and overwrite a shed load of stuff.
This is in all in:
/sys/amd64/amd64/sys_machdep.c
in the function:
int amd64_set_ldt(td, uap, descs)
The FreeBSD advisory contains a patch for all “supported” versions; but what if you’re using an older one? Using the information from Core it’s easy enough to patch. But what else is affected?
To save you the trouble, I’ve looked back at earlier versions. The problem code definitely exists in the AMD64 versions for 8.x, but isn’t present in any 7.x, as far as I can tell. The system call simply doesn’t exist. On i386 versions, I can’t see any obvious problem with the code.
How worried should we be? If someone breaks in to a system with shell access, they will be able to crash it. However, I think it’s very unlikely that any service is written in such a way that malicious data could cause the necessary parameters to be sent to sysarch() call. In fact, on checking the ports collection, it’s not exactly used all over the place. You’re highly unlikely to be running any application that even makes the call.
There’s a bug in all by the most recent versions of the Android operating system that can theoretically allow attackers to take over the device simply by viewing a web page or downloading a media file. It’s actually in the Stagefright library, and was the talk of Black Hat last August. Then it was considered hard to exploit, but security researcher Hanan Be’er at North-Bit in Israel has now published a paper proving it’s very dangerous.
Stagefright is the name of the media processing library found in all versions of Android you’re likely to find. It opens and reads any media downloaded to the device. With a specially crafted file you can cause it to crash when it does this; you don’t have to even play the file. However, it has been difficult to make use of this fact to “break out” and do anything more nasty.
Since Android 5.0, a system called Address Space Layout Randomisation (ASLR) has been in use. Basically the memory space is shuffled randomly so malicious code doesn’t know where anything else is, making attacks more difficult. This made exploiting Stagefright’s flaws a lot harder. The fact that the problem exists on Android 2.2 to 4.x, which doesn’t do ASLR, has been the subject of much complacency. Google has released fixes for the bug, known as CVE-2015-3864, but by no means have all the Android devices been updated. I guess that the vast majority have not, including the recent ones using Android 5.x. The infrastructure for updating Android simply doesn’t exist. Apple’s devices are very exploitable, but at least they have a mechanism for updating them.
So how does the North-Bit exploit work? It’s actually very straightforward. First you deliver a dodgy video file to the device; putting it on a web site is the obvious, easy method. This will cause Stagefright to crash and restart in a known state. When it does this, some JavaScript running on the same page slurps various parameters on the system, such as the current location of libc, and sends it back to the attacker. A new video file is then created and sent using this information, and it’s game over – possibly after a few tries, but North-Bit says the exploit is reliable.
How worried should we be? I’d say we should be very worried. Unless your device manufacturer and/or mobile network rolls out the patch, I can’t see any mitigation.
Tim Cook – time he was sent to jail?You can’t have missed the furore over Apple’s refusal to help the CIA get the data from a terrorist murderers iPhone. On the one side the CIA says that we need the data to protect the public, a line with the judiciary of the USA agrees with, and Apple should do everything possible to get it for them. On the other side there’s Apple’s PR engine trying (successfully) to spin the story and avoid complying with the court order.
In the mean time the Brazilians haven’t shown such deference to a cultural icon when it comes to Facebook owned WhatsApp refusing to hand over data concerning a major drugs trafficker, even after several court orders. The Brazilian authorities have arrested Diego Dzodan, Facebook’s hancho in Latin America, and thrown him in jail until such time as the company obeys the law.
Perhaps he Americans could try that with Tim Cook – you break the law, you go to jail.
Meanwhile, Apple might seem to be setting itself up as the criminals friend over this. In the land of the free where profit is king, I guess their money is as good as anyone else’s so perhaps we should be too judgemental. But in an outrageous spin, Apple has told the world that if they comply with the court order then all Apple handsets will have a backdoor and no longer be secure. This is disingenuous. The situation is this:
Apple encrypts the data stored on the phone. You have to enter a password to unlock it. If you enter ten wrong passwords it will wipe the data from the phone. The CIA has asked Apple to modify this handset to disable the data wiping feature, so the CIA can then just keep throwing passwords at it until it unlocks. Clearly, this is going to have no physical effect on any other handset anywhere else in the world. So what’s Apple’s problem?
If Apple helped the CIA break in to the handset, Apple can no longer claim that its handsets are invulnerable. Terrorists, fraudsters and anyone up to something will know that the authorities can get at Apple data even more easily than if it was stored on iCloud. Note well: the fact that Apple hasn’t produced the mod needed to do this (publicly), doesn’t mean that its not possible right now; and it may even be happening. But Apple wants to maintain the illusion that it can’t.
Put another way, it’s easy enough to bypass the locks on a front door. You just need a large enough sledge hammer. Doubt this? Look at the footage of a police raid taking place – a few burly coppers with a battering ram and it’s open in seconds. Apple is selling locks and trying to pretend there’s no such thing as a sledgehammer.
So why, might one ask, don’t the US authorities stop messing around and get the court order enforced? Are they really scared of Apple?
What’s really worrying about this situation is that “civil liberties campaigners” and some corporate America is rushing to put out statements in Apple’s defence. In other words, big business reckons it’s above the law made by the people using a democratically elected government.
dobe Flash (the browser plug-in) is notorious as a security risk, and the current batch of known exploits does nothing to improve it’s reputation. Sorry Adobe.
long last, the BBC micro:bit has 
There’s a bug in all by the most recent versions of the Android operating system that can theoretically allow attackers to take over the device simply by viewing a web page or downloading a media file. It’s actually in the Stagefright library, and was the talk of Black Hat last August. Then it was considered hard to exploit, but security researcher Hanan Be’er at North-Bit in Israel has now 