* Posts by Michael Wojcik

4973 posts • joined 21 Dec 2007

Destroying the city to save the robocar

Michael Wojcik

Re: Obviously the solution is....

Poor weather is a barrier to cycle adoption, true, but it can be engineered around

Or ignored. Plenty of people here in Michigan have bicycles. It builds character.

For that matter, I believe I've seen some people riding bicycles in poor weather in Europe and Asia.

1
0

Who's using 2FA? Sweet FA. Less than 1 in 10 Gmail users enable two-factor authentication

Michael Wojcik

It's the failure modes

Please, if you haven't already done so, just enable two-step authentication.

Sigh. Because there's no reason other than laziness why anyone hasn't, eh?

Iain, perhaps - and I'm just going out on a limb here - you should try to find out why people haven't enabled 2FA before lecturing them about it.

I'm only on the first page of comments, and I've already seen numerous posts pointing out the failure modes with phone-based authenticators. While OTA does remove some of the ones SMS is prey to (and don't get me started on people still using SMS as an authentication mechanism...), it requires additional software and a present, working smartphone.

Google's 2FA also doesn't accommodate shared accounts or delegated access. If I'm unavailable, I want my wife and kids to be able to get into my account.

Quite simply the costs and risks of 2FA are greater than the risks of password-only authentication for everything I use Google for. Google's existing 2FA would be a security downgrade.

1
0

Oracle says SPARCv9 has Spectre CPU bug, patches coming soon

Michael Wojcik

Is it really that difficult to understand?

To be fair, these attacks aren't very old, for people who don't make a habit of studying these things. And there's a great deal of noise about them. So I think we should make some allowance for confusion.

As I wrote in another post, the advantage of a side-channel attack (like the Spectre family) is that it doesn't directly violate any permissions boundaries. That's what a side channel is: an information leak that happens even when all the architected permissions are enforced correctly.

If SSM flushes the cache line on a trap, that would make inter-process Spectre a little more complicated. Flushing a line has timing effects too, though. I haven't thought about this rigorously, but I think a bounds-checked-access Spectre attack could make use of SSM by timing cache flush effects. And I don't know that SSM actually flushes the line - it might just trap and leave the line loaded, in which case it wouldn't affect most Spectre attacks at all.

Here, the fundamental issue is that CPUs have various features to make things go faster (because that's what buyers want), and those features can't be successful 100% of the time (because CPUs aren't magic). The discrepancy between faster and slower execution leaks information about the CPU's internal state.

If you want immunity from timing side-channel attacks, you need a CPU that either doesn't try to make things go faster (basically, a deterministic constant time for any given operation), or one that's magic. Or you only allow any given CPU to run "friendly" code - workloads completely under your control, or where there's no sensitive information, or where there's little reward for leaking it.

More realistically, you introduce various mitigations until you believe Spectre-class attacks are more expensive than other holes in your system, driving attackers toward those. Then you have a different problem to deal with. This is what we call "job security".

1
0
Michael Wojcik

Re: Confused, SPARC vulnerable or not?

All CPUs that perform speculative execution and have any sort of software-visible side channel (which would be all CPUs that perform spec-ex, except possible in quite unusual embedded applications) are vulnerable to the Spectre family of attacks.

If such a CPU is used to run workloads with trust boundaries - i.e. where any part of any program should not have access to any piece of data - then you have a Spectre vulnerability.

The beauty of side channel vulnerabilities like Spectre is that they do not need a failure of the permissions mechanism, so even a semi-capability architecture like IBM's i has Spectre vulnerabilities. All you need is speculative execution, a side channel, and a trust boundary.

1
0
Michael Wojcik

The JRE, like other managed-language JITers and interpreters, has 1) gadgets that are useful for Spectre-class attacks (bounds-checked accesses and indirect branches, plus others not described in the Spectre paper), and 2) ample and interesting trust boundaries. Spectre-class attacks most definitely apply to the JRE.

But that just means the JRE is an obvious target. Nearly all non-trivial applications running on a superscalar processor with speculative execution are potential Spectre targets. And that means basically all modern general-purpose computers, except some1 smartphones.

As more native compilers come out with Spectre-mitigation features, I imagine Oracle will be rebuilding the Oracle JRE with at least the most prominent Spectre gadgets protected. And you can always build a Spectre-resistant (though never Spectre-proof) OpenJDK JRE yourself. LLVM, GCC, and MSVC all have Spectre mitigation options available, at least as preliminary patches, for some CPUs.

1Some ARM CPU designs have spec-ex; others don't. I believe Apple has announced that their ARM-based iPhone CPUs have spec-ex. I don't have a good sense for what the smartphone CPU market looks like, so I couldn't guess percentages. Older phones are unlikely to have speculatively-executing CPUs, so time to dust off that Symbian 6 Nokia? (Really, given the hilariously poor security of typical smartphone OSes, I can't see many people trying to mount Spectre-class attacks against them, other than for research and lulz.)

1
0
Michael Wojcik

Re: It is a serious, fundamental design flaw

Yes, as we've repeatedly reported since January 2

True. However, "design flaw" is debatable, and Simon's "the Spectre processor design flaw" is worse.

Modern general-purpose computers are rife with side channels. Spectre is a class of vulnerabilities - not singular - that involve the interaction of speculative execution and side channels.

Inter-process side channels were always going to exist on any timesharing system, so the only candidate for "flaw" is speculative execution. Since spec-ex does exactly what it was intended to do, achieves its goal, and was clearly rewarded by the marketplace, it's hard to see how calling it a "flaw" is justified. An intruder can break one of windows of my house and gain entry - that doesn't mean windows are a design flaw.

The flaw is in imagining that modern general-purpose CPUs provided some magic, inviolable guarantee of trust boundaries. That's due to a fundamental misunderstanding of IT security, which is never about absolutes. It's about risks, probabilities, and work factors. The Spectre paper showed that the work factor for using unprivileged-software-accessible side channels to violate various trust boundaries was lower than commonly supposed.

Eliminating spec-ex would (by definition) prevent Spectre attacks, but not other side channel attacks. Increasing the work factor for particular side channels and attack vectors described in the Spectre literature (as we've seen with browser and OS vendors over the past couple of weeks) just means attackers have to switch to other side channels and attack vectors. These mitigations will always be partial, and they quickly approach a point of diminishing returns. Probably the only way to get cost factors higher after that is to reduce the number and degree of trust boundaries on a physical machine.

3
0

Meltdown/Spectre fixes made AWS CPUs cry, says SolarWinds

Michael Wojcik

Re: Kafka? Cassandra?

"Beware of geeks bearing graphs!"

Gave you a thumbs-up, but actually I think Cassandra was an optimist. She kept telling people what was going to happen, despite a history of being ignored.

0
0

Let's Encrypt plugs hole that let miscreants grab HTTPS web certs for strangers' domains

Michael Wojcik

Re: Liability

The philosophy of Let's Encrypt - which for most purposes is just the philosophy of the HTTPS Everywhere movement - is that DV (Domain Validation) certificates should not be understood as proof of identity, just proof that you're connecting to an endpoint with a given name.

Personally, I'm no great fan of LE, or HTTPS Everywhere, or the devaluing of DV certificates. But in practice DV certificates issued for payment by commercial CAs were pretty much worthless, since commercial CAs have done such an incredibly poor job.

What we really need is something between the ever-less-useful DV certificates and the expensive, hard-to-use EV certificates. The Code Signing Working Group decided last year that EV certificates should be required for code signing, for example, which causes all sorts of problems.1 For example, EV certificates require the key be kept on a FIPS 140-2 Level 2 (or better) HSM, and the options there are either awkward2 or very pricey.

Just another way that the public X.509 PKI is a disaster...

1If you obey the dictats of the CSWG, that is. Initially Microsoft said they were going to enforce them, but they backed off after the backlash from developers.

2Mostly uncloneable USB tokens, so you can only have one signing server per key, which means RAS issues and big costs if you need more than one server.

0
0
Michael Wojcik

Re: Too much trust being put into certificates?

PKI is hard.

The public hierarchical1 X.509 PKI is a huge frickin' mess. Anyone who's looked closely at it knows that. There are plenty of presentations (e.g. "The OSI of a New Generation"), papers, and books (e.g. Ristic's Bulletproof TLS) that detail the many, many problems with X.509 itself, in specification and implementation; and with how the public X.509 PKI was constructed out of it.

But I've yet to see a PKI proposal that doesn't have problems. Yes, the modern OpenPGP PKI, with its combination of traditional PGP partial-trust and web-of-trust features on the one hand and well-known keyservers on the other, does better in some respects. And there are theoretical schemes like Identity-Based Encryption that have other advantages. They all also have flaws.

And more importantly we have inertia. There's no widely-deployed TLS mechanism to use a PKI other than hierarchical X.509. Moving to one would require updates to browsers and servers, and probably a TLS extension. Look how long it's taking to roll TLS1.3 out. Completely replacing the PKI is almost certainly out of the question.

And as DV certificates continue to be devalued, EV certificates become an important source of revenue for the remaining CAs (which in turn are quickly consolidating into a handful of large players in a sea of tiny, generally even-less-reliable local ones). They won't take kindly to further undermining the paying part of the certificate business.

1There are standards for non-hierarchical X.509 trust topologies - there's an RFC that I can't be bothered searching for at the moment, for example - but none are widely deployed.

0
0

Boffins split on whether Spectre fix needs tweaked hardware

Michael Wojcik

Re: Would a separate privileged TLB help?

most of the attacks seem to be caused by the TLB having unprivileged and unprivileged memory references simultaneously in the TLB

That only applies to Meltdown, not to Spectre. There are plenty of security boundaries between different pieces of unprivileged (usermode) code. In the Spectre paper, they specifically show a Javascript exploit in a browser (so a malicious script could harvest session cookies and other sensitive data from other pages). Other obvious examples are shared systems where a malicious user steals data from other users, or from programs that deal with sensitive data such as PII, payment information, etc.

What about splitting the TLB in future processors?

That's basically what the Linux KPTI patches emulate, and the Intel PCID feature provides some hardware support to make TLB partitioning easier. So yeah, this is a mitigation strategy for Meltdown.

0
0
Michael Wojcik

Re: Interesting fix

it can in fact be patched even on the Note 4/etc by periodically flushing unused areas of the chip

I'm curious what you mean by "periodically" here. Note there are potential Spectre1 vulnerabilities between hyperthreads running on the same core, and within even a single process. So, are you going to "flush" on every context switch?

And what are "unused areas"?

with zeros or a PRNG based test pattern such as dummy data from the back camera in dark (ie case) mode

A completely unnecessary complication.

Look, it's nice that people are thinking about these things, but why are you referring to this as an "interesting fix" and prefacing it with "I may have found out how to patch"? There are plenty of people who understand CPU ISAs and microarchitectures who are looking closely at the family of spec-ex + side-channel vulnerabilities. I have no problem with people who don't understand those things making wild-ass guesses, but presenting them as possible fixes (and then getting upvoted, presumably by other people who don't understand them) just muddies the waters. Why not ask whether something is a feasible fix?

1It's not an acronym. Please don't write in block capitals.

0
0
Michael Wojcik

Re: Non-timing side channels?

Yes, there are side channels that aren't timing channels. Most of them are difficult to read purely from software, though; they're things like power consumption (very effective against many embedded systems) and EFI/RFI emissions. These side channels have been exploited in real-world, feasible PoCs, but at least they generally require some sort of physical proximity.

Perhaps more importantly, timing side channels do not require high-precision timers. The successful PoC Javascript attack in the Spectre paper didn't use a high-precision timer; it used a WebWorker thread decrementing a counter in a shared array. There are many timer alternatives, even in Javascript; and remote (over the network) timing attacks have been successfully demonstrated.

Also, a lower-resolution or jittery timer means you have to make more measurements to reach the same degree of confidence in the data. But when you're trying to extract something like a private key, password, or session token, getting the bits with, say, 80% certainty is still pretty good; it cuts your brute-force effort exponentially.

Blocking access to high-precision timers is spot defense - it's just pruning off the low-hanging branches.

0
0

UK.gov puts Suffolk 7-year-old's submarine design into production

Michael Wojcik

Re: Art World

Piss Christ is 30 years old

About time for a resurrection, then?

Someone get the ball rolling. It's time for this thing to see the light of day.

1
0

IBM’s complete Meltdown fix won’t land until mid-February

Michael Wojcik

Spectre, not Meltdown

POWER CPUs are vulnerable to Spectre. It's unlikely they're vulnerable to Meltdown.

Spectre is a very broad class of attacks that affects most modern CPUs.

Meltdown only applies to CPUs that are subject to Spectre-class attacks and do not enforce permissions on speculative loads. And even then, Meltdown only applies if you have higher-privilege pages mapped when running at low privilege, which is an OS architectural choice.

0
0
Michael Wojcik

VMs, where there are multiple VMs running on a single physical system, and they have isolation requirements. Anything running in the cloud, for example. Anything running in a data center where different VMs have different regulatory requirements.

Javascript drive-by attacks.

All of this has been discussed at great length, and is in the original papers.

0
0

1980s sci-fi movies: The thrill of being not quite terrified on mum's floral sofa

Michael Wojcik

Sure. I'm still hoping for a Director's Cut that includes several more hours of the Mystics strolling along, with the occasional one bursting into flames.

0
0
Michael Wojcik

Re: The Thing...

The "Quatermass and the Pit" original BBC TV serial (1958) was really scary in black&white on a very small screen. In later years they revealed how they did the special effects in real time by quite simple means.

A lot of it was just the directing and acting, in my opinion. I haven't seen Quartermass and the Pit in decades, and I can still picture characters crouching in an alley as the wind blows rubbish about them. It's a cinematic cliche, but the scene in QatP is the one that sticks with me. It was done very effectively.

The effects were nice, for the time, but they supported the actors rather than displacing them.

0
0

How are the shares, Bry? Intel chief cops to CPU fix slowdowns

Michael Wojcik

Re: Intel microcode update

Does it ... disable speculative execution? Change how kernel code is cached? Does it do F- all?

It may be the update to enable IBRS.

I haven't seen a good description of IBRS yet, but presumably it does what it says on the tin - restricts when the CPU will speculatively execute an indirect branch. Unfortunately that's only one Spectre variant.

As for performance hit: Anyone's guess, but note where indirect branches are most commonly used: things like bytecode interpreters, state machines, and other logic constructs that are often implemented with some sort of jump table. Will it hit C++ virtual-method (vtable) invocation? I dunno. Meltdown fixes are easier to guess about, because we know when a process will context-switch from kernel to user, but estimates for those are still all over the place.

2
0
Michael Wojcik

Re: Follow the chip designers

This isn't a case of "everyone making the same mistake" it is a case of no one having any idea this type of attack was even theoretically possible.

That's not really accurate. After Paul Kocher published his first timing-attack papers in the mid-90s, we knew it was theoretically possible. And indeed we've had several years of very successful cache timing attack demonstrations.

Also, if you look at the history of the Meltdown/Spectre disclosures, you'll find Kocher and Horn and Gruss, and probably others, talking about what prompted them to look for these issues. It was prior work or comments by other researchers, or personal projects that had been cooking for a while. It's more a case that, prior to last summer, no one who had put two and two together decided to publish.1

That's why we had four teams independently discovering Meltdown and Spectre (combined) over a few months. The necessary ideas have been in the air for years. Hell, Spectre isn't even the first family of Javascript-in-browser drive-by cache-timing attacks. And using side channels to recover data across privilege boundaries is old hat.

1Maybe there isn't anyone who'd developed these attacks earlier, but that seems pretty unlikely. I'm considering this the first public discovery, not the first actual discovery.

1
0
Michael Wojcik

Re: Follow the chip designers

As this Intel's Meltdown problem has been around since 1995 it should be possible to track from the earliest CPU the designers involved and how they have influenced other chip designers to have it appear in Apple's and Qualcomm's ARM chips.

As Meltdown doesn't apply to Apple's and Qualcomm's existing ARM chips - only to a core family which isn't in production yet - it shouldn't be necessary.

In any case, there's nothing particularly subtle about Meltdown. Here's how it works:

  • Do you have a processor with speculative execution? OK.
  • Does your processor have an MMU, i.e. provide memory protection? OK.
  • Does your OS keep privileged pages mapped when context-switching to unprivileged code? OK.
  • Does your processor allow speculative loads from privileged pages when running in unprivileged code? Bingo - you have Meltdown.

The first three are pretty much universal for modern general-purpose CPUs. The last is the one that makes a difference. When you're designing your spec-ex circuitry, do you have it make that privilege-boundary check? It's not immediately obvious you should, because you know it's going to throw a fault and discard the results, so they're not directly visible anyway.

The whole idea of spec-ex is "program didn't see it, I didn't do it". Unfortunately side channels make a mockery of that idea.

1
0
Michael Wojcik

Re: Not really

because they already have a pile of 0 days for those which are far worse

I agree, mostly, but it's important to note that Spectre in particular is nicely general (doesn't depend on the OS) and pretty much undetectable, which makes it potentially useful even for the widely-used OSes.

But you're right that for the common OS cases they have better attacks readily available. Well-resourced attackers would probably use CPU-targeting attacks like Meltdown and Spectre mostly against niche systems.

1
0
Michael Wojcik

which I imagine is the only timer with sufficient resolution to measure a cache miss

You imagine wrong, I'm afraid. Read the Spectre paper; their PoC in Javascript on Chrome didn't even use a proper timer, just a WebWorker thread continually decrementing a value in a shared array.

Side-channel information leakage is a probabilistic game, not all-or-nothing. Degrade the accuracy of the timer and the attacker just needs more iterations to derive a result with sufficient probability to be useful. (Consider, for example, that an attacker who gets the bits in a password or private key or session cookie with 90% now has reduced the brute-force work factor by an order of magnitude.)

Degrading the timer increases the attack work factor, which is useful in some situations; degrading it a lot may even make the attack infeasible. But just degrading it a little doesn't do the job.

4
0

IBM melts down fixing Meltdown as processes and patches stutter

Michael Wojcik

These security holes aren't trivial to exploit, yet.

Spectre is easy to exploit in drive-by Javascript. There's sample code in the original Spectre paper, and the countermeasures introduced by browser vendors are laughable.1 I'm not sure how much closer to "trivial" you want.

1They've basically disabled the two high-precision timing mechanisms used in the paper. There are several others available to scripts, and they're well-documented. One of the key papers describing them was linked to from the comments on another Reg article recently.

3
0
Michael Wojcik

Re: Red Hat on AIX virtualization

the short-lived AIX-5L port to Itanium has long since disappeared, and AIX/PS2 is a dead product

But let us not forget the also-gone original AIX for the RT PC, AIX/370, and AIX/ESA.

Anyway: Meltdown (it's not an acronym, so there's no reason to write it in block caps) only applies to CPU+OS combinations where pages with different read permissions are mapped into a single address space, and speculative execution ignores those read permissions. Currently, that's only x86 and one ARM core family (which isn't in production yet).

The much larger Spectre (also not an acronym) family of attacks are generally possible, in some form, on any CPU that provides speculative execution and any side channel that permits indirect analysis of load contents. The attacks in the Spectre paper use cache timing, but the paper notes some of the other possible side channels.

Spectre has been confirmed against x86, AMD, ARM, POWER, z, some nVidia GPUs, and by now probably other processor architectures. Because spec-ex is well-known and long-established for high-performance general-purpose processors, Spectre attacks are widely applicable.

1
0

Take notebooks: About those new Thinkpads...

Michael Wojcik

Re: Next time, Dell

I've used perhaps a dozen Dell models (all employer-supplied) over the past couple decades, and every single one has had some glaring design flaw.

The Latitude E6540 I'm using right now suffer from a couple of them:

  • Annoying: The machine has a key sequence, Fn-Alt-B, which (when enabled in the BIOS) turns off all the lights. Screen backlighting, keyboard backlighting, activity lights, power lights... everything. It's very nice when I'm staying in a hotel room and I want to leave the beast on overnight, but don't want it lighting up the room like a friggin' Christmas tree. But: the power supply cable has a blue LED that shines with the brightness of a thousand suns. It's on the barrel connector that plugs into the laptop, and it's mounted in a ring of lucite that goes around the barrel so you can't just flip it over to hide it, as you could with the old LED-on-the-transformer-brick design. And there's no way to turn it off, short of unplugging the thing. Stupid, stupid, stupid. So I have electrical tape wrapped around the barrel connector.
  • Criminal: Dell wants to prevent people from using third-party power supplies (so they can charge a premium). So they designed the world's worst lock-in system. It's incredibly fragile, both to mechanical and electrical damage. If it breaks, then 1) the laptop will no longer charge the battery, and 2) the BIOS throttles the CPU (to "save battery life"). If it breaks in the charger, then in theory you can pony up $60 or so for a new, vastly overpriced Dell charger. If it breaks on the laptop, and you're not under warranty, then Dell provides the "ha ha no, you're fucked" remedy.

I would never, ever buy a Dell for my personal use. There is something deeply wrong with that firm.

1
0

More stuff broken amid Microsoft's efforts to fix Meltdown/Spectre vulns

Michael Wojcik

Re: Is GPU also too?

GPUs won't be vulnerable to Meltdown, because they don't have privilege levels. At least I'm not aware of any that do.

GPUs traditionally did not provide speculative execution; their die space went to features that improved compute-intensive SIMD workloads. See for example this 2009 whitepaper on nVidia's Fermi architecture. The Spectre family of attacks depends on speculative execution.1

I haven't paid attention to the last several years' developments in GPU architectures, though, and it's conceivable that designers have started incorporating more speculation features into them.

Better questions: What might a side-channel attack like Spectre achieve on a GPU? Spectre is only interesting if the attack code can gain access to data that it shouldn't be able to read. And are there better existing attacks on such data? For that question, you might want to look at the CUDA Leaks paper from 2013. Again, obviously, that's relatively old, and memory protection in GPUs may have moved forward.

1However, it's entirely possible that there are other memory-probing side-channel attacks which don't require spec-ex, as I've noted in comments on other stories.

0
0

Here come the lawyers! Intel slapped with three Meltdown bug lawsuits

Michael Wojcik

Re: Should Intel (and other chip makers) be held responsible for hardware flaws?

Intel's x86-64 CPUs are more complex than CPUs need to be in order to support backward compatibility to the architecture.

That has nothing to do with Meltdown or Spectre.

Meltdown exists because of an architecture choice: allow speculative loads across privilege boundaries (i.e., don't make a privilege check before allowing a speculative load). That's why AMD x86 CPUs don't suffer from it - it's just one of the choices you can make when implementing the x86-64 ISA.

Spectre exists because the CPUs provide speculative execution and caches. So do pretty much all general-purpose CPUs. x86-64 would never have survived in the market, at least not for server systems, if it hadn't adopted those. Lack of speculation is one of the reasons Itanium had so much trouble bringing its performance up, and with the very deep pipelines of x86 (necessary for adequate performance with backward compatibility), a non-speculative x86 would not have been competitive.

x86 has had spec-ex since 1995, with the Pentium Pro. In fact it had it back in 1994 with the NexGen Nx586, but that was never widely used and NexGen was purchased by AMD in '95. (As far as I know, neither the earlier NexGen design nor competing chips from AMD and Cyrix did spec-ex, though the techniques date back at least to the late 1980s.)

0
0
Michael Wojcik

Re: timing attacks

Given that JS is interpreted and does not have direct memory access, just how is it is going to be used to trigger Specter, let alone Meltdown flaws?

If only there were a freely available paper that explained this...

First, note that modern browsers all JIT Javascript into machine code. It's not interpreted by any of the major browsers, at least in their default mode.

The Javascript PoC is for Spectre, not Meltdown. And it's quite straightforward. All you need is the pieces required for a cache-timing attack (easily achieved in Javascript with a high-res timer and a byte array), and a suitable gadget, which you can write in the script itself. The gadget just does a conditional read from memory; by (mis-)training the branch predictor, you can get the CPU to speculatively execute the load with an out-of-bounds address.

The Spectre paper authors disassembled the JITed Javascript so they could tweak the source to produce the instruction sequence they wanted, but that's just a shortcut; a script could easily include different variations.

0
0
Michael Wojcik

RISC-V would at least be susceptible to Specter

Yup. What the RISC-V folks are saying is that "no current RISC-V designs are vulnerable", not that it's impossible to design a RISC-V CPU which is.

It's hard to prevent Spectre in hardware. Either you give up speculative execution, or you identify all the feasible side channels. Good luck with the latter, and I'm not yet convinced that there aren't Spectre-like attacks which don't need spec-ex.

Where you see a side channel, start by assuming it can be used to leak information to an adversary, until proven otherwise. (Where "proven otherwise" usually means demonstrating that the maximum bandwidth of the channel, after accounting for errors, is too low to be useful.)

0
0
Michael Wojcik

Re: OK, I'll bite

The problem is NOT the OS. It's the CPU not functioning as documented, i.e. NOT accessing memory in which the page table says "do not access it", even if it does so only briefly.

While Meltdown does involve speculative access across privilege levels, Spectre does not. And if you believe either of the attacks violates something in the CPU specification, I'd like to see a citation. CPU specifications tend to be quite vague and leave a great deal of room for the implementation.

In particular, memory-protection features are described in terms of their direct effects on registers and memory, not on microarchitectural features such as the caches. There's no magical guarantee that memory protection prevents ever loading anything from an unpermitted page into a CPU storage area that's not directly accessible by the executing program.

What you wish CPUs would do, and what they're documented as doing, are two different things.

0
0
Michael Wojcik

Re: OK, I'll bite

The obvious solution for Spectre would be to add some bits of the pointer to the head of the page table into the branch history table indices

That only helps with one of the two Spectre variants demonstrated in the original paper, and in that paper the authors point to other side channels which are probably also usable for Spectre attacks (e.g. ALU contention). Blinding the BTB would be a bandaid.[1]

As anyone with a crypto background knows, it's really hard to reduce all your side channels to the point where they leak information too slowly to feasibly exploit. Paul Kocher showed us that more than 20 years ago, a mere 7 years after the DEC branch-prediction patent was granted.

[1] Sticking plaster, for CPUs in the Commonwealth.

0
0
Michael Wojcik

Re: OK, I'll bite

it has been stated that you won't experience slowdowns unless you are doing a lot of disk access or network access

That may have been stated (by whom?). That doesn't mean it's correct.

The Meltdown remediations cause a performance hit for all kernel-to-user context switches. I/O is a major cause of such switches, but it certainly isn't the only one.

Software-based Spectre remediations,[1] once they start appearing in software, will cause a performance hit every time they're encountered. As hardware assist for them is introduced in new CPUs (such as the new conditional branch instructions ARM describes in their Spectre whitepaper) the cost will drop, but for older CPUs the techniques that have been identified so far, such as memory fences and retpolines, are significantly expensive.

[1] Aside from the initial stopgaps put into browsers, which were simply to defeat the two cache-timing mechanisms identified in the Spectre paper.

0
0

Woo-yay, Meltdown CPU fixes are here. Now, Spectre flaws will haunt tech industry for years

Michael Wojcik

Re: Itanic, S/Z

The two server grade processors that are definitely not effected are by this issue are Itanic and IBM's System/z.

"affected", not "effected".

You're wrong about z. Redhat and SUSE have both announced Spectre PoC for z.

I suspect you're wrong about Itanium too, since it does speculative loads.

0
0
Michael Wojcik

Spectre has been demonstrated for POWER and IBM z.

I don't see how SPARC and MIPS would not be vulnerable to Spectre. Basically you need speculative execution, an L1 cache, and a high-precision timer. Those are all found in essentially all modern general-purpose CPUs.

Specific Spectre variants might not be possible on a given architecture, but it's a broad family. The initial Spectre paper only describes two variants, but as Paul Kocher can tell you, there are side channels everywhere.

Spectre is basically this year's Rowhammer.

0
0
Michael Wojcik

Re: Error?

How does one know if they've just gotten a password, or random garbage?

Perhaps you should look at the published proofs of concept, which do indeed show successful exploit of both Meltdown and Spectre.

I know, I know. Reading is hard, while posting rubbish is easy.

0
0
Michael Wojcik

Re: Error?

Hum, lower resolution timers will just mean that the attack code will have to make more attempts to determine the difference between the two branches; it won't plug the vulnerability.

Not necessarily; if the resolution is low enough (the grain large enough) then error can dominate to the point where it's infeasible to ever gather sufficient information. It's pretty hard to determine cache timing with 1-second resolution, for example; you'd have to take an enormous number of measurements.

More importantly, they also introduce jitter, so there's additional error.

Even more importantly, though, timing is not the only side channel in CPU microarchitectures. It's just a matter of time until someone has a PoC using some other channel. It may not be pure software (it might use RFI or something, for example), but we've seen those side channels exploited in practice - for example using an innocuous-looking device placed near the target system.

0
0
Michael Wojcik

Re: Was Intel Aware?

That is, an area marked unusable that actually is still good. Effectively invisible, but still accessible to those parts of the system that are informed about the "good bad spots".

That's how i imagine one could fix this problem, together with another system of pseudo-randomly storing the vulnerable data in pseudo-randomly different spots.

No, that wouldn't help.

This is really quite complicated, but: The issue with Spectre is that while speculative execution discards incorrect results, it has side effects on system state. When spec-ex loads data from memory into cache, that changes the contents of that cache line and the address it's associated with. An unprivileged process can't read those contents - that's essential to virtual memory in a multiprocessing system with process isolation, like every modern general-purpose OS. But an unprivileged process may be able to figure out something about the address the cache line is associated with.

How? With a cache timing attack, for one. Cache timing is one of many side-channel attacks against CPU microarchitectures. Basically, you try to read a particular address and see how long it takes for the load to complete. If it's fast, then you know that address was already cached.

Cache timing leaks information - it lets the attacker find out something about what addresses have recently been cached. That may not seem relevant, but if you're a security engineer, you know that any information leak has the potential to serve as a side channel that reveals some secret information.

For one Spectre variant, you find a piece of code that does an indirect load based on an address you (the attacker) supply. That is:

1. You run the code, supplying address X.

2. The code loads value V1 from X.

3. The code uses V1 to retrieve some value V2 from another location. There's a set of possible V2 addresses, and they depend on V1.

For example, consider a bytecode interpreter which does something like:

result = Functions[*X](...);

that is, it looks at the byte at X, and uses that to index into an array of function pointers.

Now: The attacker wants to know what byte is at some address A, but doesn't have read permission for that virtual address. So he passes A to that block of code. The CPU speculatively executes up through the point of retrieving the function address from the array slot. Then the attacker users cache timing to figure out which function address was loaded. That tells the attacker the value of the byte at A. (The attacker has previously done some setup work.)

That's greatly oversimplified, but it's the basic idea for that form of Spectre.

So having unreadable memory (which we already have), or moving sensitive data around (which we already do), don't help. It's the speculative load and its effect on the cache which matter.

3
0

Whizzes' lithium-iron-oxide battery 'octuples' capacity on the cheap

Michael Wojcik

Re: Nevertheless...

I'm highly interested in the return of phones that only need to be charged once a week.

My Asus phone typically goes 4 or 5 days on a charge, which isn't "once a week" but is much, much better than any other Android phone I've had.

If I shut down everything non-essential I could probably get it to last a week.

1
0

Game of Thrones author's space horror Nightflyers hitting telly

Michael Wojcik

Re: Personally I'd quite like to see the "Tuf Voyaging" collection on screen

I was going to say the same. I've been reading GRRM for a while (I read the original short story of "Sandkings" when it was published in Omni, a few centuries ago), but Tuf Voyaging remains my favorite of his. It's a solid fix-up and the first story in particular is very cinematic.

And because it's a fix-up, it would be easy for new viewers to start watching at any point.

0
0

Magic Leap blows our mind with its incredible technology... that still doesn't f**king exist

Michael Wojcik

Did VCR or DVD or Blu-Ray have killer apps?

Time-shifting was a "killer" application of VCRs. That radically changed how many people consumed television. It dramatically altered television programming and advertising. Anyone who watched television programming even in moderation in the pre- and post-VCR eras ought to know that; anyone who didn't (and hasn't studied the history) probably shouldn't be commenting on it.

The "killer" application of DVDs was the shift of commercial film releases from VCR tapes to DVDs, which drove DVD-player sales - though those already had a toehold due to video-game consoles.

There has yet to be a killer application of Blu-Ray, which is just more DVD. It's popular with consumers who want that, and ignored by those who don't.

Frankly, I don't see a killer application for VR/AR, except in some specific industrial domains. I first saw a working VR implementation at SIGGRAPH 1989. I thought it was a gimmick then, and none of the subsequent demos, applications, or speculative pieces I've seen have changed my mind. Even if Magic Leap produces a product that does everything they claim, it won't change how I use computers.

2
0

Another AI attack, this time against 'black box' machine learning

Michael Wojcik

Isn't it? I mean, that ought to be pretty clear if you're familiar with the terminology.

You start with an image that the classifier gets right. You make big changes to it until the classifier gets it wrong. You gradually tweak it to be closer and closer to the original, until you get something very close to the original that the classifier still gets wrong.

CS researchers (like all other researchers) catch a lot of flak over their prose style, and it's often deserved. But this particular sentence is quite straightforward while remaining technically specific.

0
0
Michael Wojcik

Re: let's look at this a little sceptically

One potential is to perturb signs in the real world for autonomous or assisted cars

Yes. More generally, it shows DNN-based classifier models are even more fragile in the face of active attacks than was previously generally acknowledged. Indeed, at least some of them are so fragile that they can plausibly misidentify an input[1] due to small random perturbations.

That has very serious consequences for use cases such as autonomous vehicles. It's a very important avenue of research.

Recent research into understanding what's actually happening in DNNs[2] may help.

[1] That is, assign it to the wrong class, rather than to the null class. It's a precision failure, not just a recall failure.

[2] See e.g. https://blog.acolyer.org/2017/11/15/opening-the-black-box-of-deep-neural-networks-via-information-part-i/.

0
0

PHWOAR, those noughty inks: '0.1%' named Stat of The Year

Michael Wojcik

Around here, I could get hit by a bus every 20 seconds.

But surely it's the quality of the impact that matters?

0
0
Michael Wojcik

Re: The UK has much more in the way of peat bogs (9.4 per cent).

Indeed! "Remember the Antrim!" has always been my rallying cry when considering blanket peat.

I'll confess that I have, at times, neglected Sperrins.

0
0

Erase 2017 from your brain. Face ID never happened. The Notch is an illusion

Michael Wojcik

Re: Prefer authentication on the front of the phone

iPhone needs two hands to unlock the display. The Pixel needs one.

The Motie phone requires all three hands. :(

0
0

I, Robot? Aiiiee, ROBOT! RSA TLS crypto attack pwns Facebook, PayPal, 27 of 100 top domains

Michael Wojcik

Re: So..... People Using Libraries Are Liable To Get Pwned

There's nothing in the article or the exploit page to say this is comes from a specific library, OSS or not.

Indeed, it does not.

I was one of the folks who had early, embargoed knowledge of ROBOT, and tested some TLS implementations for it (using Böck's Python client, now available on the ROBOT site). Like other Bleichenbacher variants, it's due to the sort of error that's easy to make, and thus can easily appear in independent implementations.

Specifically, the ROBOT oracle is how a server responds to various sorts of malformed messages. When the responses to different malformed messages also differ (in a "useful" way, which I'm not going to try to define here), that leaks some information about the server's RSA private key.[1] By varying the messages you leak different bits. It's pretty easy to determine just how much information is being leaked, so you can tell how many messages would be required to get enough of the key to brute-force the remainder. And that tells you whether an attack is feasible at a given technology-and-money point.

There are a lot of failure paths in RSA key exchange, so it's not hard to see why an implementation might not do exactly the same thing on all of them. This makes RSA Kx fragile, as the ROBOT page (and the article) points out. So removing it, or at least preferring DH/ECDH (preferably their ephemeral variants) suites, is a good option.

This can also be seen as a variation of Moxie Marlinspike's Cryptographic Doom Principle: If you don't validate the message as the very first thing you do, you're going to be sorry. Marlinspike was specifically talking about verifying the MAC, but ensuring the message is well-formed also applies.

Vulnerable ROBOT implementations are written in a variety of languages. Some are relatively old and some quite new. Some are proprietary closed source, and others are open. Some are embedded in appliances, and those are going to be the ones to look out for.

[1] Which is why this attack only applies if the connection is using RSA key exchange. It doesn't work against signing, only against encryption, so it's not a problem if the connection uses DH or ECDH key exchange, as the article mentions at the end.

2
0

FREE zero-day for every reader: AT&T's DirecTV kit has a root hole – and no one wants to patch it

Michael Wojcik

Re: Well so where's the problem?

you run a "reflection attack"

Yup. All the attacker needs is for you to visit a page with a CSRF vulnerability. Of which there are approximately one zillion.

Pivot-and-escalate is one of the most common attack approaches. Everyone in IT should know that.

It's not a problem that the owner (or renter, or however the agreement with AT&T works) can get root. It's a problem that anyone can, trivially.

1
0

OK, OK, MIRA-I DID IT: Botnet-building compsci kid comes clean

Michael Wojcik

Re: Not even Putler?

Glad to see someone mentioned Krebs' piece. That was a good bit of investigation on his part, and I'd been waiting to see whether it would be confirmed.

0
0

One per cent of all websites probably p0wned each year, say boffins

Michael Wojcik

Rounding down a bit, are we?

The title says "each year", but the article and the university's announcement both say the study determined nearly 1% were hacked over an 18-month period.

It's been a long year, figuratively, but I'm pretty sure chronologically it was the usual number of months.

Still, as others have said, it's a nice study and methodology. Nothing astounding but often the useful results aren't.

0
0

FCC douses America's net neutrality in gas, tosses over a lit match

Michael Wojcik

Re: Next Question? Whens the Investigation start?

Face it, this process on the face of it looks like a classic case of a public official being purchased.

But it isn't. Pai didn't have to be purchased by telcos as a public official; they've owned him since he was in the private sector. Verizon doesn't hire lawyers on the strength of their ethics or independence.

5
0

Forums

Biting the hand that feeds IT © 1998–2018