The Mandelbear's Musings

What Were You Thinking, Patreon?

2022-09-11T02:23:28Z

So, a couple of days ago (September 8th, to be exact) Patreon laid off their entire five-person security team. WTF? The linked article goes on to say,

The firm, which is still doing business in Russia, simply calls it “a strategic shift” (which seems to be corporate mumbo-jumbo for “cheaper outsourcing”). But infosec experts call it a “nightmare” caused by an “untrustworthy” company that’s “just put a massive target on its back.”

You can see links to more articles below in the resources.

The minimum reasonable response to this would be to change your password. Done that. It's not unreasonable to delete your account. I'm still supporting a few sites, so I'll leave my account in place until I see what's going to happen. And laying in a supply of popcorn.

Resources

@ Patreon confirms it 'parted ways' with its 'entire' cyber security team | IT PRO
Patreon confirms security team layoffs | TechCrunch
Patreon Fires its Security Team — and the Internet Freaks Out
Patreon Just Let Its Entire Security Team Go [Updated]
Should You Delete Your Patreon Account After They Laid Off Their Entire Security Team? - Dhole Moments -> excellent discussion of risks and alternatives -> changed password. Probably ought to delete account too, but I'm using it.

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

Why, and How to, Secure your S3 Storage

2020-01-24T04:38:23Z

If you've ever looked into cloud storage (like for backups -- you do make backups, right?) you will recognize Amazon's Simple Storage Service, otherwise known as S3. It was the first of the Amazon Web Services to be released, in 2006. It's cheap ($0.023 per GB per month for up to 50TB, after which you get a bit of a discount), extremely reliable, and secure.

According to this article on "How to secure an Amazon S3 Bucket",

Here’s what you need to know to lock down an Amazon S3 bucket:
Step one: do nothing. [emphasis theirs]
Yes, do nothing because — like all other AWS services — the default configuration provides a strong security posture right out of the gate.

So when you create an S3 "bucket" (which is what they call the container you store your files in -- bits in a bucket?), only you can do anything with it. After that, if necessary, you can give other people access. Or open it up for everyone to see, for example if you want to host a website on it. (There are better places to host a website.)

If you're storing sensitive information like customer names and addresses, you can have Amazon encrypt it for you. For really sensitive things, like social security numbers and credit card information, you can encrypt it on your end. Amazon gives you some useful tools that make it easy. But this post isn't a tutorial on S3 security -- Amazon has one right here. This is, I don't know, kind of a <rant>.

Because, in spite of the fact that you have to do extra work to make a bucket public, I keep running into articles like Leaky Buckets: 10 Worst Amazon S3 Breaches and, more recently, Adult Site Leaks Extremely Sensitive Data of Cam Models.

Yes, S3 buckets can be used to exchange data with other companies or people -- if you're careful. Encrypted. Multiple times. With strictly limited access. And public buckets can be used for hosting media files and even whole (static) websites (although download bandwidth, while cheap, is not usually free -- a DDOS attack or suddenly going viral can saddle you with an appallingly high bill). But for goodness' sake don't confuse the two!

</rant>

Ask yourself these questions:

Will I be absolutely delighted if a thousands of random people on FB saw this file I'm storing? If the answer is "yes", make it public. Otherwise, consider making it private.
Will I have a problem if certain people (my business competitors, my mother, my ex, ...) saw this file? If so, you should make it private, and use at least server-side encryption.
Will I get in trouble (lawsuits, identity theft, public shaming in blog posts like this one, ...)? Encrypt it. Use client-side encryption if you want to be sure. Encrypt the filenames, too. And keep it encrypted when it's stored on your computers, as well. (In many cases there are government regulations that cover exactly how you should handle this data. Some things shouldn't be stored at all, like credit card PINs. But always encrypt.)

Resources

Here is the Amazon documentation for securing data on S3. There's more, but these are the basics.

... and here are a few other links, collected here for your convenience.

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

Patch your Windows 10 boxes.

2020-01-17T02:01:03Z

If your Windows 10 boxes -- all of them, both desktops and servers, didn't apply the update that came out Tuesday, go do that now. You can chase the references below while the update is downloading.

Here's what Microsoft said about it when they released the patch. There are more details in the resource list below. Some of those go on to link to proof-of-concept exploits. Good luck!

h/t to @thnidu.

Resources

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

Update Firefox NOW

2020-01-10T19:50:57Z

Unlike my post Wednesday, this is one you should do Right Now(TM) if you have Firefox installed and aren't getting automatic updates. And even if you're getting updates automatically, you should check your version if you haven't updated since Wednesday. This vulnerability is being actively exploited in the wild.

The latest version is 72.0.1; you can check this by choosing the "About" item on the "Help" menu. The corresponding Android version is 68.4.1; "About" is the last item on the "Settings" menu. The update doesn't appear to be necessary on iOS (presumably because it's using a different just-in-time (jit) compiler)-- version 20.0 was released back in October.

Links

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

SHA-1 is a SHA-mbles

2020-01-08T21:02:53Z

I haven't put on my curmudgeon's hat in way too long. This isn't going to be a very long post, and if you don't know what a hash function is and what it's used for, all you need to do is make sure you're keeping up with security upgrades. Modern web browsers are already safe, and have been for the last three years or so; if you're still using a browser older than that, you should upgrade it. Some other programs in common use are not safe yet, so watch for security upgrades in the coming months.

If you're still with me, I just wanted to point the people who worry about such things at the latest vulnerability-with-a-catchy-name: SHA-1 is a Shambles. Tl;dr: the cost to construct a pair of different messages with the same SHA-1 hash has dropped to well under $100K worth of rented GPU time. Attacks still aren't exactly practical -- they used 900 GPUs for a couple of months -- but it's only a matter of time.

Section 7 of the paper [PDF] goes into detail on current usage of SHA-1 and what is being done about it. SHA-1 has been deprecated since 2011, and is no longer allowed in digital signatures. There are, however, still some older programs and protocols where it's an option, and X.509 certificates are still being issued with SHA-1 signatures (although modern browsers will reject them). They're being fixed, but you should make sure gpg, ssh, and web browsers are up to date, and if you're a developer, please stop using or accepting keys or certificates with SHA-1 signatures.

Git uses SHA-1 hashes to identify objects, and indirectly to sign commits. The developers are working on using longer hashes, and it now includes collision-detection; I'll be particularly interested in that work going forward.

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

comments

The Apache .htaccess vulnerability

2018-10-23T21:04:42Z

There’s an article about a security problem getting a bit of attention lately, Apache Access Vulnerability Could Affect Thousands of Applications. Sounds really scary. Here’s a better article about it, Zero-day in popular jQuery plugin actively exploited for at least three years. Looking at those titles you might think that the problem is either with a jQuery plugin, or Apache’s .htaccess files. It’s neither. The real situation is more complicated. You might think that if you’re not using this plugin on your website, you’d be safe. You’d be wrong. You might think that patching the plugin, or the Apache web server, would solve the problem. You’d be wrong about that, too. The real problem is still there, waiting to bite you in the tail. If you don’t have a website, or don’t allow file uploads, you can stop reading now unless you’re curious. If you do, stick around (or jump to the last section if all you want is the fix).

The problem being reported

You may have noticed that the two titles up there are highlighting different aspects of the problem. There’s that “popular jQuery plugin”, blueimp/jQuery-File-Upload. People building websites use it to allow their users to upload files (e.g., cat pictures). It’s really popular – 7800 forks on GitHub, 29,000 stars; probably tens or hundreds of thousands of sites using it. And then there’s the Apache web server. Apache is even more popular – it runs some 45% of the web. Since there are presently just short of two billion websites (although all but a couple of hundred million are currently active). And more specifically and specifically htaccess files, which are used to override certain server configuration options (including security options, which is almost as scary as it sounds, but doesn’t have to be).

The specific problem is this: jQuery-File-Upload lets visitors to a web site upload their cat pictures. These get put in a directory somewhere in the server’s file system. If you’re running a website and have any sense, you’ll put that directory someplace where it can’t be seen from the web, but of course that means that your visitors can’t see the cat pictures they’ve uploaded, without you or your software doing some work, and that could be tricky.

If you have a directory that’s part of your website that you want to be invisble from the web, or visible safely (we’ll get into that a little later), there are two ways to set that up. If you have access to Apache’s configuration files, you do it there. Unfortunately that requires root access, and most of us are using shared servers and our hosting sites don’t allow that, because it would be a huge security hole if they did. The other way of configuring your site is to put a file called .htaccess somewhere on your site, and it will apply configuration overrides to that directory and everything below it. That’s a little dicey, because it’s possible to get that wrong, especially if you’re not an experienced system administrator, but if you’re operating a shared hosting service like the one I use, you have to give your users some way of setting parameters, and .htaccess is the only game in town.

Finally there’s the fact that, some ten years ago, Apache changed the defaults on their server so that .htaccess files are disabled, so the administrator has to specifically re-enable them. What does that mean?

Well, if you are allowing users to upload files, and if you put the upload directory where it can be seen from the web (meaning that people can download from it), and if you were counting on a .htaccess file to protect that directory, and if you upgraded Apache any time in the last ten years, and if you or your system administrator didn’t re-enable .htaccess files, and if you thought that your .htaccess file was still protecting you, then you have a problem. That’s a lot of “if”s, but there are an awful lot of websites.

Here’s how this situation can be exploited, as reported by a security researcher at Akamai named Larry Cashdollar, in an article titled Having The Security Rug Pulled Out From Under You.

If you can upload files to a website, all you have to do is:

1$ echo '<?php $cmd=$_GET['cmd']; system($cmd);?>' > shell.php
2$ curl -F "files=@shell.php" http://example.com/jQuery-File-Upload-9.22.0/server/php/index.php

It’s not hard. The first line there creates a one-line file with some PHP code in it. The second line uploads it. Now you have a file called shell.php on the server. You can send a request for that file with a query string attached to it, and PHP will helpfully pass that string to the system, which runs it. Boom.

The problem with the reporting

Here are a couple of passages quoted from the ZDNet article:

The developer’s investigation identified the true source of the vulnerability not in the plugin’s code, but in a change made in the Apache Web Server project dating back to 2010, which indirectly affected the plugin’s expected behavior on Apache servers.

…

Starting with [version2.3.9], the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via .htaccess files. This setting was made for security reasons, was enabled by default.

Actually, what happened was that the server disabled .htaccess files by default, and it was done for performance reasons – having to read .htaccess files with every request is a big performance hit. Here’s what the Apache documentation says about it:

.htaccess files should be used in a case where the content providers need to make configuration changes to the server on a per-directory basis, but do not have root access on the server system. In the event that the server administrator is not willing to make frequent configuration changes, it might be desirable to permit individual users to make these changes in .htaccess files for themselves. This is particularly true, for example, in cases where ISPs are hosting multiple user sites on a single machine, and want their users to be able to alter their configuration. [emphasis mine]

The DARKReading Article adds,

A security vulnerability is born, Cashdollar said, when a developer looks at very old documentation and uses .htaccess for authentication instead of one of the methods now suggested by the Apache Foundation.

Well, no. The documentation is still current, and it’s very clearly marked as something you shouldn’t use unless you have to. And most of the people who have vulnerable websites aren’t developers, don’t have any choice about whether to use .htaccess, and aren’t reading the docs. They’re just doing cut-and-paste from the quick-start documents that their web host provides.

What’s the real problem?

There are a couple of things that the articles I’ve refererred to didn’t mention, or just glossed over.

The first is that uploading files is a problem, and it’s been a problem since long before there was a World Wide Web! I first ran into this while running an FTP server. There are all sorts of ways file uploads can be abused. Somebody can bring down your server by uploading junk and filling your disk. They can upload malware. It has nothing at all to do with jQuery-File-Upload; this has been a problem since day 1.

The solution, if you must allow uploads, is to upload them to someplace safely outside of your website, and process them immediately – either with your server-side code, or a cron job. This is just as much common sense as not using any form data until it’s been validated and sanitized. Some languages, like Perl, give you some help with this. This is true on the client side too, if you have JavaScript. Validate your inputs! I ran into that one last week, you may remember.

The second problem is PHP. Actually, the problem is putting executable files in your website instead of someplace like a CGI script directory, or a web server. But PHP is the biggest offender. It was designed to make it so easy to build a website that anyone could do it. And everyone did.

PHP was designed to be simple. It wasn’t designed to be safe. (It has a lot of other problems, too, but that’s the big one.) See Why PHP Sucks and PHP: a fractal of bad design, for example.

The biggest problem with PHP is that it works by mixing executable executable code with the documents you’re serving to the user. Sure, it’s convenient. It’s also bad design – it’s a series of disasters waiting to happen, and this is only the most recent one.

What should you do?

Obviously, if you have access to your server’s configuration, you should disable .htaccess and do everything at the server level. That’s not always possible.
If you aren’t using PHP on your website, disable it.
At the very least, disable PHP in your upload directory!
If you want to let users upload files, put them someplace outside your document root and keep them there until you or your software can review them for safety. (When I was running an FTP server, I had separate ‘incoming’ and ‘outgoing’ directories.)

You may find Disable PHP in a directory with Apache .htaccess - Electric Toolbox helpful: just put these three lines into an .htaccess file, either at the top level of your site, or down in any directories where it’s not needed (which includes not only your upload directory but also image directories and other assets, just to be sure).

RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
php_flag engine off

While you’re at it, make it so that the web server – and anyone else who isn’t you – can’t write into your website files:

1cd your_server's_document_root
2chmod -R go-w .

Have fun, be safe out there, and don’t use PHP.

Another fine post from The Computer Curmudgeon.

comments

PSA: Data breach at Newegg

2018-09-21T21:38:24Z

TL;DR: if you bought anything from Newegg between August 14th and September 18th, call your bank and get a new credit card. You can find more details in these articles: NewEgg cracked in breach, hosted card-stealing code within its own checkout | Ars Technica // Hackers stole customer credit cards in Newegg data breach | TechCrunch // Magecart Strikes Again: Newegg in the Crosshairs | Volexity // Another Victim of the Magecart Assault Emerges: Newegg

The credit-card skimming attack appears to have been done by Magecart, the organization behind earlier attacks on British Airways and Ticketmaster. If you are one of the customers victimized by one of these attacks, it's not your fault, and there isn't much you could have done to protect yourself (but read on for some tips). Sorry about that.

This article, Compromised E-commerce Sites Lead to "Magecart", gives some useful advice. (It's way at the end, of course; search for "Conclusion and Guidance".) The most relevant for users is

An effective control that can prevent attacks such as Magecart is the use of web content whitelisting plugins such as NoScript (for Mozilla’s Firefox). These types of add-ons function by allowing the end user to specify which websites are “trusted” and prevents the execution of scripts and other high-risk web content. Using such a tool, the malicious sites hosting the credit card stealer scripts would not be loaded by the browser, preventing the script logic from accessing payment card details.

Note that I haven't tried NoScript myself -- yet. I'll give you a review when I do. They also advise selecting your online retailers carefully, but I'm not sure I'd consider, say, British Airlines to be all that dubious. (Ticketmaster is another matter.)

Impacts of a Hack on a Magento Ecommerce Website, which talks about an attack on a site using the very popular Magento platform, gives some additional advice:

Shy away from sites that require entering payment details on their own page. Instead prefer the websites that send you to a payment organization (PayPal, payment gateway, bank, etc) to complete the purchase. These payment organizations are required to have very strict security policies on their websites, with regular assessments, so they are less likely to be hacked or miss some unauthorized modifications in their backend code.

They also suggest checking to see whether the website has had recent security issues, and using credit cards with additional levels of authentication (e.g. 2FA -- two-factor authentication).

Things are more difficult for retailers, but the best advice (from this article, again) is

Stay away from processing payment details on your site. If your site never has access to clients’ payment details, it can’t be used to steal them even if it is hacked. Just outsource payments to some trusted third-party service as PayPal, Stripe, Google Wallet, Authorize.net, etc.

Which is the flip side of what they recommend for shoppers. If the credit card info isn't collected on your site, you're not completely safe, but it avoids many of the problems, including Magecart. Keep your site patched anyway.

If you insist on taking payment info on your own site, and even if you don't, the high-order bit is this paragraph:

E-commerce site administrators must ensure familiarity and conformance to recommended security controls and best practices related to e-commerce, and particularly, the software packages utilized. All operating system software and web stack software must be kept up to date. It is critical to remain abreast of security advisories from the software developers and to ensure that appropriate patch application follows, not only for the core package but also third-party plugins and related components. [emphasis mine]

Be careful out there! ( links )

Another fine post from The Computer Curmudgeon, cross-posted to computer-curmudgeon.com.

comments

PSA: Security

2018-09-06T17:52:20Z

Actually two PSAs.

First: Especially if you're running Windows, you ought to go read The Untold Story of NotPetya, the Most Devastating Cyberattack in History | WIRED. It's the story of how a worldwide shipping company was taken out as collateral damage in the ongoing cyberwar between Russia and the Ukraine. Three takeaways:

If you're running Windows, keep your patches up to date.
If you're running a version of Windows that's no longer supported (which means that you can't keep it patched, by definition), either never under any circumstances connect that box to a network, or wipe it and install an OS that's supported.
If at all possible, keep encrypted offline backups of anything really important. (I'm not doing that at the moment either. I need to fix that.) If you're not a corporation and not using cryptocurrency, cloud backups encrypted on the client side are probably good enough.

Second: I don't really expect that any of you out there are running an onion service. (If you had to click on that link to find out what it is, you're not.) But just in case you are, you need to read Public IP Addresses of Tor Sites Exposed via SSL Certificates, and make sure that the web server for your service is listening to 127.0.0.1 (localhost) and not 0.0.0.0 or *. That's the way the instructions (at the "onion service" link above) say to set it up, but some people are lazy. Or think they can get away with putting a public website on the same box. They can't.

If you're curious and baffled by the preceeding paragraph, Tor (The Onion Router) is a system for wrapping data packets on the internet in multiple layers of encryption and passing them through multiple intermediaries between you and whatever web site you're connecting with. This will protect both your identity and your information as long as you're careful! An onion service is a web server that's only reachable via Tor.
Onion services are part of what's sometimes called "the dark web".

Be safe! The network isn't the warm, fuzzy, safe space it was in the 20th Century.

Another public service announcement from The Computer Curmudgeon.

comments

PSA: Venmo users check your privacy settings!

2018-07-21T04:19:20Z

If you're using the popular social/money-transfer phone app Venmo check your privacy settings!! It seems that the default is that every transaction you make is public! It is difficult for me to express just how broken this is. In case you're having trouble grasping the implications, just go to PUBLIC BY DEFAULT - Venmo Stories of 2017. There you will find profiles of five unsuspecting Venmo users -- one of them is a cannabis retailer -- whose transactions were among the over two hundred thousand exposed to public view during 2017.

The site is a project of Mozilla Media Fellow Hang Do Thi Duc. She has some other interesting things on her site.

It's worth noting that Venmo is owned by PayPal, and that according to a PayPal spokesperson quoted in this article on Gizmodo the public-by-default nature of person-to-person transfers (person-to-business transactions are private) is apparently a deliberate feature, not a bug.

“Venmo was designed for sharing experiences with your friends in today’s social world, and the newsfeed has always been a big part of this,” a company spokesperson told Gizmodo, asserting that the “safety and privacy” of its users is a “top priority.”

Yeah. Right.

Here are more articles at The Guardian, Lifehacker, and CNET.

"We make it default because it's fun to share [information] with friends in the social world," a Venmo representative told CNET Friday. "[We've seen that] people open up Venmo to see what their family and friends are up to."

Because it's fun. Kind of puts it in the same category as other "fun" things like cocaine, binge drinking, and unprotected sex, doesn't it?

This has been a public service announcement from The Computer Curmudgeon. With a tip of the hat to Thnidu.

comments

efail

2018-05-15T14:41:40Z

If your mail client automatically decrypts mail, read this!

There's no need to panic, but you should immediately disable and/or uninstall plugins that automatically decrypt PGP-encrypted or S/MIME email. The linked article tells you how.

The vulnerability is called EFAIL (the obligatory website with clever name), and allows an attacker to read your encrypted email, in effect "over your shoulder", by sending you a modified version of the encrypted message. They can do this by evesdropping, compromising an email account or server, etc. The attack is based on the way active content, such as images, is handled in HTML email.

Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy&pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.

Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.

Links below:

  @ EFAIL Paper [PDF]
  @ Critical PGP and S/MIME bugs can reveal encrypted emails—uninstall now [Updated]
  @ Attention PGP Users: New Vulnerabilities Require You To Take Action Now | EFF
  @ Not So Pretty: What You Need to Know About E-Fail and the PGP Flaw | EFF

This has been a public service announcement from The Computer Curmudgeon.

comments

Meltdown and the Spectre of Speculation

2018-01-09T03:21:14Z

TL;DR: Patch your computer NOW! (Or as soon as you can, if you're running Windows or Ubuntu and reading this on Monday -- the official release date for this information was supposed to have been Tuesday January 9th.)

Unless you've been hiding under a rock all weekend, you probably know that Meltdown and Spectre have nothing to do with either nuclear powerplants or shady investments: they are, instead, recently-revealed, dangerous design flaws in almost all recent computers. Meltdown affects primarily Intel processors (i.e. most desktops, laptops, and servers), and will be mitigated (Don't you just love that word? It doesn't mean "fixed", it means "made less severe". That's accurate.) by the recent patches to Linux, Windows, and MacOS. Spectre is harder to exploit, but also harder to fix, and may well present serious problems going forward.

But what the heck are they? I'm going to try to explain that in terms a non-geek can understand. Geeks can find the rest of the details in the links, if they haven't already chased them down themselves. (And if you're in software or IT and you haven't, you haven't been paying attention.)

Briefly, these bugs are hardware design problems that allow programs to get at information belonging to other programs. In the case of Meltdown, the other program is the operating system; with Spectre, it's other application programs. The information at risk includes things like passwords, credit card and bank account numbers, and cryptographic keys. Scared yet?

Basically, it all comes down to something called "speculative execution", which means something like "getting stuff done ahead of time just in case it's needed." And carefully putting things back the way they were if it turned out you didn't. That's where it gets tricky.

Modern computers are superscalar, which means that they achieve a lot of their impressive speed by doing more than one operation at once, and playing fast-and-loose with the order they do them in when it doesn't matter. Sometimes they make tests (like, "is this number greater than zero?", or "is that a location the program doesn't have permission to read?"), and do something different depending on the result. That's called a "branch", because the program can take either of two paths.

But if the computer is merrily going along executing instructions before it needs their results, it doesn't know which path to take. So, in the case of Spectre, it speculates that it's going to be the same path as last time. If it guesses wrong (and Spectre makes sure that it will by going down the safe path first), the computer will get an instruction or two down the wrong path before it has to turn back and throw away any results it got. Spectre makes it do something with those results that leaves a trace.

In the case of Meltdown, the test that's going down the wrong path is to see whether the program is trying to read from memory that belongs to the operating system kernel -- that's the part of the OS that's always there, managing resources like memory and files, creating and scheduling processes, and keeping programs from getting into places where they aren't permitted. (There's a lot of information in the kernel's memory, including personal data and passwords; for this discussion you just need to know that leaking it would be BAD.) When this happens, the memory-management hardware interrupts the program before it receives its ill-gotten data; normally the result is that the program is killed. End of story. On Intel processors, though, there's a way the program can say something like "if this instruction causes an interrupt, just pretend it never happened." The illegally-loaded data is, of course, thrown away.

Meltdown works because the operating system's memory is -- or was -- part of the same "address space" as the application program. The application can try to read the kernel's memory; it just gets stopped if it tries. After Tuesday's patch, the two address spaces are going to be completely separate, so the program can't even try -- the kernel's address space simply isn't there. (There's a performance hit, because switching between the two address spaces takes time -- that's why they were together in the first place.)

At this point you know what Spectre and Meltdown do, but you may be wondering how they manage to look at data that simply isn't there any more, because the instruction that loaded it was canceled. (If you're not wondering that, you can stop here.) The key is in the phrase "any more". During the brief time when the data is there, the attacker can do something with it that can still be detected later. The simplest way is by warming the cache.

Suppose you go out to your car on an icy morning and the hood feels warm. Maybe one of the local hoodlums took it out for a joyride, or maybe one of the neighbor's cows was sitting on it. You can tell which it was by starting the engine and seeing whether it's already warmed up. (We're assuming that the cow doesn't know how to hotwire a car.) The attack program does almost the same thing.

The computer's CPU (Central Processing Unit) chip is really fast. It can execute an instruction in less than a nanosecond. Memory, on the other hand, is comparatively slow, in part because it's not part of the CPU chip -- electrical signals travel at pretty close to the speed of light, which is roughly a foot per nanosecond. There's also some additional hardware in the way (including the protection stuff that Meltdown is sneaking past), which slows things down even further. We can get into page tables another time.

The solution is for the CPU to load more memory than it needs and stash (or cache) it away in very fast memory that it can get to quickly, on the very sensible grounds that if it needs something from location X now, it's probably going to want the data at X+1 or somewhere else in the neighborhood pretty soon. The cache is divided into chunks called "lines" that are all loaded into the cache together. (Main memory is divided into "pages", but as I mentioned in the previous paragraph that's another story.)

When it starts a load operation, the first thing the CPU does is check to see whether the data it's loading is in the cache. If it is, that's great. Otherwise the computer has to go load it and the other bytes in the cache line from wherever it is in main memory, "warming up" the cache line in the process so that the next access will be fast. (If it turns out not to be anyplace the program has access to, we get the kind of "illegal access exception" that Meltdown takes advantage of.)

The point is, it takes a lot longer to load data if it's not in the cache. If one of the instructions that got thrown away loaded data that wasn't in the cache, that cache line will still be warm and it will take less time to load data from it. So one thing the attack program can do is to look at a bit in the data it's not supposed to see, and if it's a "1", load something that it knows isn't in the cache. That takes only two short instructions, so it can easily sneak in and get pre-executed.

Then, the attack program measures how long it takes to load data from that cache line again. (One of the mitigations for the spectre attack is to keep Javascript programs -- which might come from anywhere, and shouldn't be able to read your browser's stored passwords and cookies -- from getting at the high-resolution timers that would let them measure load time.)

Here under the cut are a basic set of references, should you wish to look further. Good stuff to read while your patches are loading.

( Notes & links )

comments

PSA: PHP Must Die

2014-10-30T14:01:30Z

Advisory 01/2014: Drupal - pre Auth SQL Injection Vulnerability

A "highly critical public service announcement" from Drupal [LWN.net] "Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 - Drupal core - SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement."

Impressive. I think this is an appropriate place to quote one of my father's aphorisms: "A locked car with an open window is NOT a locked car."

If PHP is your open window, you may as well leave the keys on the dashboard where they're easy to see.

comments