Security Hacks

1459 Articles

Joykill: Previously Undisclosed Vulnerability Endangers User Data

January 17, 2018 by 28 Comments

Researchers have recently announced a vulnerability in PC hardware enabling attackers to wipe the disk of a victim’s computer. This vulnerability, going by the name Joykill, stems from the lack of proper validation when enabling manufacturing system tests.

Joykill affects the IBM PCjr and allows local and remote attackers to destroy the contents of the floppy diskette using minimal interaction. The attack is performed by plugging two joysticks into the PCjr, booting the computer, entering the PCjr’s diagnostic mode, and immediately pressing button ‘B’ on joystick one, and buttons ‘A’ and ‘B’ on joystick two. This will enable the manufacturing system test mode, where all internal tests are performed without user interaction. The first of these tests is the diskette test, which destroys all user data on any inserted diskette. There is no visual indication of what is happening, and the data is destroyed when the test is run.

A local exploit destroying user data is scary enough, but after much work, the researchers behind Joykill have also managed to craft a remote exploit based on Joykill. To accomplish this, the researchers built two IBM PCjr joysticks with 50-meter long cables.

Researchers believe this exploit is due to undocumented code in the PCjr’s ROM. This code contains diagnostics code for manufacturing burn-in, system test code, and service test code. This code is not meant to be run by the end user, but is still exploitable by an attacker. Researchers have disassembled this code and made their work available to anyone.

As of the time of this writing, we were not able to contact anyone at the IBM PCjr Information Center for comment. We did, however, receive an exciting offer for a Carribean cruise.

Intel Forms New Security Group To Avoid Future Meltdowns

January 17, 2018 by 57 Comments

Intel just moved some high level people around to form a dedicated security group.

When news of Meltdown and Spectre broke, Intel’s public relations department applied maximum power to their damage control press release generators. The initial message was one of defiance, downplaying the impact and implying people are over reacting. This did not go over well. Since then, we’ve started seeing a trickle of information from engineering and even direct microcode updates for people who dare to live on the bleeding edge.

All the technical work to put out the immediate fire is great, but for the sake of Intel’s future they need to figure out how to avoid future fires. The leadership needs to change the company culture away from an attitude where speed is valued over all else. Will the new security group have the necessary impact? We won’t know for quite some time. For now, it is encouraging to see work underway. Fundamental problems in corporate culture require a methodical fix and not a hack.

Editor’s note: We’ve changed the title of this article to better reflect its content: that Intel is making changes to its corporate structure to allow a larger voice for security in the inevitable security versus velocity tradeoff.

Apple Passwords: They All ‘Just Work’

January 12, 2018 by 40 Comments

When the Macintosh was released some thirty-odd years ago, to Steve Jobs’ triumphant return in the late 90s, there was one phrase to describe the simplicity of using a Mac. ‘It Just Works’. Whether this was a reference to the complete lack of games on the Mac (Marathon shoutout, tho) or a statement to the user-friendliness of the Mac, one thing is now apparent. Apple has improved the macOS to such a degree that all passwords just work. That is to say, security on the latest versions of macOS is abysmal, and every few weeks a new bug is reported.

The first such security vulnerability in macOS High Sierra was reported by [Lemi Ergin] on Twitter. Simply, anyone could login as root with an empty password after clicking the login button several times. The steps to reproduce were as simple as opening System Preferences, Clicking the lock to make changes, typing ‘root’ in the username field, and clicking the Unlock button. It should go without saying this is incredibly insecure, and although this is only a local exploit, it’s a mind-numbingly idiotic exploit. This issue was quickly fixed by Apple in the Security Update 2017-001

The most recent password flaw comes in the form of unlocking the App Store preferences that can be unlocked with any password. The steps to reproduce on macOS High Sierra are simply:

  • Click on System Preferences
  • Click on App Store
  • Click the padlock icon
  • Enter your username and any password
  • Click unlock

This issue has been fixed in the beta of macOS 10.13.3, which should be released within a month. The bug does not exist in macOS Sierra version 10.12.6 or earlier.

This is the second bug in macOS in as many months where passwords just work. Or don’t work, depending on how cheeky you want to be. While these bugs have been overshadowed with recent exploits of Intel’s ME and a million blog posts on Meltdown, these are very, very serious bugs that shouldn’t have happened in the first place. And, where there are two, there’s probably more.

We don’t know what’s up with the latest version of the macOS and the password problems, but we are eagerly awaiting the Medium post from a member of the macOS team going over these issues. We hope to see that in a decade or two.

Spectre And Meltdown: Attackers Always Have The Advantage

January 10, 2018 by 45 Comments

While the whole industry is scrambling on Spectre, Meltdown focused most of the spotlight on Intel and there is no shortage of outrage in Internet comments. Like many great discoveries, this one is obvious with the power of hindsight. So much so that the spectrum of reactions have spanned an extreme range. From “It’s so obvious, Intel engineers must be idiots” to “It’s so obvious, Intel engineers must have known! They kept it from us in a conspiracy with the NSA!”

We won’t try to sway those who choose to believe in a conspiracy that’s simultaneously secret and obvious to everyone. However, as evidence of non-obviousness, some very smart people got remarkably close to the Meltdown effect last summer, without getting it all the way. [Trammel Hudson] did some digging and found a paper from the early 1990s (PDF) that warns of the dangers of fetching info into the cache that might cross priviledge boundaries, but it wasn’t weaponized until recently. In short, these are old vulnerabilities, but exploiting them was hard enough that it took twenty years to do it.

Building a new CPU is the work of a large team over several years. But they weren’t all working on the same thing for all that time. Any single feature would have been the work of a small team of engineers over a period of months. During development they fixed many problems we’ll never see. But at the end of the day, they are only human. They can be 99.9% perfect and that won’t be good enough, because once hardware is released into the world: it is open season on that 0.1% the team missed.

The odds are stacked in the attacker’s favor. The team on defense has a handful of people working a few months to protect against all known and yet-to-be discovered attacks. It is a tough match against the attackers coming afterwards: there are a lot more of them, they’re continually refining the state of the art, they have twenty years to work on a problem if they need to, and they only need to find a single flaw to win. In that light, exploits like Spectre and Meltdown will probably always be with us.

Let’s look at some factors that paved the way to Intel’s current embarrassing situation.

Continue reading “Spectre And Meltdown: Attackers Always Have The Advantage” →

Getting A Handle On Meltdown Update Impact, Stay Tuned For Spectre

January 9, 2018 by 31 Comments

When news broke on Meltdown and Spectre ahead of the original disclosure plan, word spread like wildfire and it was hard to separate fact from speculation. One commonly repeated claim was that the fix would slow down computers by up to 30% for some workloads. A report released by Microsoft today says that “average users” with post-2015 hardware won’t notice the difference. Without getting into specific numbers, they mention that they expect folks running pre-2015 hardware to experience noticeable slowdowns with the patches applied.

The impact from Meltdown updates are easier to categorize: they slow down the transition from an user’s application level code to system level kernel code. The good news: such transitions were already a performance killjoy before Meltdown came along. There exists an extensive collection of tools (design patterns, libraries, and APIs) to help software developers reduce the number of user-kernel transitions.

Performance sensitive code that were already written to minimize kernel transitions will suffer very little from Meltdown updates. This includes most games and mainstream applications. The updates will have a greater impact on the minority of applications that frequently jump between kernel and user worlds. Antivirus software (with their own problems) have reasons to do so, and probably will end up causing most of the slowdowns seen by normal users.

Servers, with their extensive disk and networking IO — and thus kernel usage — are going to have a much worse time, even as seen through Microsoft’s rosy spectacles. So much so that Microsoft is recommending that admins “balance the security versus performance tradeoff for your environment”.

The impact from Spectre updates are harder to pin down. Speculative execution and caching are too important in modern CPUs to “just” turn off. The fixes will be more complex and we’ll have to wait for them to roll out (bumps and all) before we have a better picture.

The effects might end up being negligible as some tech titans are currently saying, and that probably will fit your experience, unless you’re running a server farm. But even if they’re wrong, you’ll still be comfortably faster than an Intel 486 or a Raspberry Pi.

Do any of you have numbers yet?

[via The Verge]

 

Raspberry Pi Ain’t Afraid Of No Spectre And Will Not Meltdown

January 9, 2018 by 43 Comments

While there’s broad agreement that Meltdown and Spectre attacks are really bad news at a fundamental level, there is disagreement on its immediate practical impact in the real world. Despite reassurance that no attacks have been detected in the wild and there’s time to roll out the full spectrum of mitigation, some want to find protection right now. If you’re interested in an usable and easy to set up modern desktop that’s free of Meltdown or Spectre threats, a Raspberry Pi can provide the immunity you seek.

[Eben Upton] explained the side channel attacks using fragments of Python for illustration, which was an enlightening read independent of the Raspberry Pi pitch. While these ARM cores perform speculative instruction fetches, they don’t speculatively execute them or modify the cache. Under the current circumstances, that makes all the difference in the world.

A clever security researcher may yet find a way to exploit speculative fetches in the future, and claiming that Raspberry Pi has superior security would be a stretch. The platform has its own set of security problems, but today Meltdown/Spectre is not among them. And that just might be enough to sway some decisions.

If you need to stay in the x86 world, look over what it’d take to to rewind back to an Intel 486.

Thanks to [D00med] for sharing the link in a comment to our overview article.

Lowering JavaScript Timer Resolution Thwarts Meltdown And Spectre

January 6, 2018 by 35 Comments

The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.

Our web browsers present a huge potential surface for attack as JavaScript is ubiquitous on the modern web. Executing JavaScript code will definitely involve the processor cache and a high-resolution timer is accessible via browser performance API.

Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.

After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.

These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.

Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.

This is just one part of the shock wave Meltdown/Spectre has sent through the computer industry. We have broader coverage of the issue here.