1446 stories

Technical analysis of Qualys' GHOST

1 Comment and 2 Shares
This morning, a This morning, leaked note from Qualys' external PR agency made us aware of GHOST. In this blog entry, our crack team of analysts examines the technical details of GHOST and makes a series of recommendations to better protect your enterprise from mishaps of this sort.

Figure 1: The logo of GHOST, courtesy of Qualys PR.

Internally, GHOST appears to be implemented as a lossy representation of a two-dimensional raster image, combining YCbCr chroma subsampling and DCT quantization techniques to achieve high compression rates; among security professionals, this technique is known as JPEG/JFIF a JPEG file . This compressed datastream maps to an underlying array of 8-bpp RGB pixels, arranged sequentially into a rectangular shape that is 300 pixels wide and 320 pixels high. The image is not accompanied by an embedded color profile; we must note that this poses a considerable risk that on some devices, the picture may not be rendered faithfully and that crucial information may will be lost.

In addition to the compressed image data, the file also contains APP12, EXIF, and XMP sections totaling 818 bytes. This metadata tells us that the image has been created with Photoshop CC on Macintosh. Our security personnel notes that Photoshop CC is an obsolete version of the application, superseded last year now made obsolete by Photoshop CC 2014. In line with industry best practices and OWASP guidelines, we recommend all users to urgently upgrade their copy of Photoshop to avoid exposure to potential security risks.

The image file modification date returned by the HTTP server at community.qualys.com is Thu, 02 Oct 2014 02:40:27 GMT (Last-Modified, link). embedded in the image is 2014-10-02 04:36:26+02:00. The roughly 90-day delay between the creation of the image and the release of the advisory probably corresponds to the industry-standard period needed to test the materials with appropriate targeted focus groups.

Removal of the metadata allows the JPEG image to be shrunk from 22,049 to 21,192 bytes (-4%) without any loss of image quality; enterprises wishing to conserve vulnerability-disclosure-related bandwidth may want to consider running jhead -purejpg to accomplish this goal.

Of course, all this mundane technical detail about JPEG images distracts us from the broader issue highlighted by the GHOST report. We're talking here talking, of course, about the fact that the JPEG compression is not particularly suitable for non-photographic content such as logos, especially when the graphics need to be reproduced with high fidelity or repeatedly incorporated into other work. fidelity. To illustrate the ringing artifacts introduced by the lossy compression algorithm used by the JPEG file format, our investigative team prepared this enhanced visualization:

Figure 2: A critical flaw in GHOST: ringing artifacts.

Artifacts aside, our research has conclusively showed that the JPEG formats offers an inferior compression rate compared to some of the alternatives. In particular, when converted to a 12-color PNG and processed with pngcrush, the same image can be shrunk to 4,229 bytes (-80%):

Figure 3: Optimized GHOST after conversion to PNG.

PS. Tavis also points out that ">_" is not a standard unix shell prompt. We believe that such design errors can be automatically prevented with commercially-available static logo analysis tools.

PPS. On a more serious note, check out this message to get a sense of the risk your server may be at. Either way, it's smart to upgrade.
Read the whole story
Share this story
1 public comment
1 day ago

Wider Borders in XFCE / Xubuntu

1 Comment

Wider Borders in XFCE / Xubuntu

A longstanding Xubuntu / XFCE UI problem has been single-pixel window borders that make click-and-drag resizing essentially impossible. The reason it’s a longstanding problem has been the developers’ unflinching response to any and all issues raised on the bug tracker:

That discussion may be illuminating.

I had never looked for the XFCE theme-building documentation (and, thus, never found any), because building a whole new theme would be a lot of work just to resize the damn borders. It should be feasible to tweak only the borders of an existing theme, but … I stalled.

Repeatedly. On every single version of Xubuntu that’s come along.

Fortunately, someone recently did the legwork and summarized the method, which I slightly adapted:

cd /usr/share/themes/
sudo cp -a Greybird-compact/ Greybird-wide
cd Greybird-wide/xfwm4
for f in bottom left right ; do sudo cp ../../Daloa/xfwm4/${f}* . ; done
sudo sed -i -e 's/C0C0C0/CECECE/' *xpm
sudo sed -i -e 's/A0A0FF/7C7C7C/' *xpm
sudo sed -i -e 's/E0E0FF/E0E0E0/' *xpm

The exact color mapping depends on which two themes you’re using. You can also specify GTK element colors, which seems like a better way to do it. Maybe next time.

Apparently, the corresponding PNG files contain transparency information for the XPM files, but I haven’t bothered to investigate how that works or what might happen if I tweaked them.

Then you select the new Graybird-wide theme and It Just Works.

Sheesh & similar remarks…


Read the whole story
23 hours ago
but I love my vulcan neck pinch window resizing.
Earth, Sol system, Western spiral arm
Share this story

Using unattended-upgrades on Rackspace's Debian and Ubuntu servers

1 Comment

I install the unattended-upgrades package on almost all of my Debian and Ubuntu servers in order to ensure that security updates are automatically applied. It works quite well except that I still need to login manually to upgrade my Rackspace servers whenever a new rackspace-monitoring-agent is released because it comes from a separate repository that's not covered by unattended-upgrades.

It turns out that unattended-upgrades can be configured to automatically upgrade packages outside of the standard security repositories but it's not very well documented and the few relevant answers you can find online are still using the old whitelist syntax.

Initial setup

The first thing to do is to install the package if it's not already done:

apt-get install unattended-upgrades

and to answer yes to the automatic stable update question.

If you don't see the question (because your debconf threshold is too low -- change it with dpkg-reconfigure debconf), you can always trigger the question manually:

dpkg-reconfigure -plow unattended-upgrades

Once you've got that installed, the configuration file you need to look at is /etc/apt/apt.conf.d/50unattended-upgrades.

Whitelist matching criteria

Looking at the unattended-upgrades source code, I found the list of things that can be used to match on in the whitelist:

  • origin (shortcut: o)
  • label (shortcut: l)
  • archive (shortcut: a)
  • suite (which is the same as archive)
  • component (shortcut: c)
  • site (no shortcut)

You can find the value for each of these fields in the appropriate _Release file under /var/lib/apt/lists/.

Note that the value of site is the hostname of the package repository, also present in the first part these *_Release filenames (stable.packages.cloudmonitoring.rackspace.com in the example below).

In my case, I was looking at the following inside /var/lib/apt/lists/stable.packages.cloudmonitoring.rackspace.com_debian-wheezy-x86%5f64_dists_cloudmonitoring_Release:

Origin: Rackspace
Codename: cloudmonitoring
Date: Fri, 23 Jan 2015 18:58:49 UTC
Architectures: i386 amd64
Components: main

which means that, in addition to site, the only things I could match on were origin and component since there are no Suite or Label fields in the Release file.

This is the line I ended up adding to my /etc/apt/apt.conf.d/50unattended-upgrades:

 Unattended-Upgrade::Origins-Pattern {
         // Archive or Suite based matching:
         // Note that this will silently match a different release after
         // migration to the specified archive (e.g. testing becomes the
         // new stable).
 //      "o=Debian,a=stable";
 //      "o=Debian,a=stable-updates";
 //      "o=Debian,a=proposed-updates";
+        "origin=Rackspace,component=main";


To ensure that the config is right and that unattended-upgrades will pick up rackspace-monitoring-agent the next time it runs, I used:

unattended-upgrade --dry-run --debug

which should output something like this:

Initial blacklisted packages: 
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,archive=stable,label=Debian-Security', 'origin=Debian,archive=oldstable,label=Debian-Security', 'origin=Rackspace,component=main']
Checking: rackspace-monitoring-agent (["<Origin component:'main' archive:'' origin:'Rackspace' label:'' site:'stable.packages.cloudmonitoring.rackspace.com' isTrusted:True>"])
pkgs that look like they should be upgraded: rackspace-monitoring-agent
Option --dry-run given, *not* performing real actions
Packages that are upgraded: rackspace-monitoring-agent

Making sure that automatic updates are happening

In order to make sure that all of this is working and that updates are actually happening, I always install apticron on all of the servers I maintain. It runs once a day and emails me a list of packages that need to be updated and it keeps doing that until the system is fully up-to-date.

The only thing missing from this is getting a reminder whenever a package update (usually the kernel) requires a reboot to take effect. That's where the update-notifier-common package comes in.

Because that package will add a hook that will create the /var/run/reboot-required file whenever a kernel update has been installed, all you need to do is create a cronjob like this in /etc/cron.daily/reboot-required:

cat /var/run/reboot-required 2> /dev/null || true

assuming of course that you are already receiving emails sent to the root user (if not, add the appropriate alias in /etc/aliases and run newaliases).

Read the whole story
1 day ago
topical given the high-impact bug in (e)glibc. I should get this set up.
Earth, Sol system, Western spiral arm
Share this story

Dear FCC: Enhanced 911 Location Services Could Endanger American’s Privacy

1 Comment and 2 Shares

The 911 system has a problem. As people switch from landlines to mobile phones, more and more 911 calls come from wireless devices. But under current FCC E911 (Enhanced 911) regulations, carriers are only required to provide 911 dispatchers with a mobile phone’s location to within 300 meters, and aren’t required to provide any sort of vertical location information (i.e. to pinpoint what floor of a skyscraper someone is on). This lack of accurate location information can make it difficult for first responders to find callers, especially when the person calling becomes disoriented or unable to speak.

Unfortunately, in an effort to solve this problem the FCC may be about to create a whole host of new ones, this time for people’s privacy. On Thursday, January 29th, the FCC will vote on new E911 rules which would require carriers to provide more accurate location information—within 50 meters horizontally, and three meters vertically—enough to pinpoint what floor of a building somebody is on. The four major carriers have proposed a roadmap [PDF] that outlines how they intend to meet these new rules when they are finalized, but this roadmap is almost completely devoid of any mention of privacy safeguards.

The Privacy Dangers

For example, the roadmap and the FCC rules aren’t clear about whether enhanced location reporting will always be on whenever the phone is on, or only available during 911 calls; or if it’s not always on, whether it will have to be triggered on the phone or could be triggered remotely. Without more specific guidelines, this could mean that carriers could use E911 regulations as an excuse to ubiquitously track the precise locations of all of their customers, both indoors and outdoors, all the time. Of course organizations like the NSA and DEA will likely demand access to that data, using the flimsy reasoning that such information is “only metadata.” There’s also the risk that state or local police might try to get this data without a warrant. While the U.S. Supreme Court made clear in U.S. v. Jones that Americans’ location history enjoys significant privacy protections, and in Riley v. California that our mobile phones are also entitled to strong privacy protections, it’s still not settled on the national level whether or not police need a warrant in order to demand location information from a mobile carrier.

And it’s not just law enforcement we should be worried about. As recent articles have explained, the world’s cell phone systems don’t exactly feature strong security. A malicious hacker or a foreign government can already extract your location from the current system without your carrier’s knowledge or consent. More accurate location information would doubtless pose an even more alluring target—and the roadmap doesn’t mention how this information will be secured.

The roadmap also poses privacy concerns for anyone using a stationary wireless device, be it a Wi-Fi router, a set-top cable box, or even a smart thermostat. That’s because carriers want to create something called the National Emergency Address Database (NEAD), which would match the Wi-Fi and Bluetooth MAC addresses of stationary devices to physical street addresses (and even apartment, suite, or floor numbers). This would enable the carriers to take advantage of the same sort of indoor location technology that companies like Google, Apple, and Skyhook already use, which use your phone’s Bluetooth and Wi-Fi antennas to scan for nearby fixed devices, and then match those MAC addresses to a database to determine your precise location.

While this sort of technology isn’t new, that doesn’t mean it doesn’t raise privacy concerns. In addition to these privacy concerns, the carriers propose going one step further by suggesting that users should be required to enter their physical address when they setup a new stationary wireless device (like a wireless router) in order to make NEAD’s coverage as comprehensive as possible. As you might expect, the roadmap doesn’t go into what sort of privacy safeguards might be built into NEAD or the smartphones that will use it, or who will have access to NEAD.

Easy Solutions

Obviously these issues pose a very real danger to Americans’ location privacy. That’s why EFF, along with numerous other privacy- and consumer-rights-focused organizations (including New America’s Open Technology Institute, the ACLU, CDT, Consumer Federation of America, Public Knowledge, Privacy Rights Clearinghouse, and several others) have called on [PDF] the FCC commissioners to make clear to carriers that any technology they use to satisfy E911 regulations must meet the following criteria:

  • E911 functionality should be designed so that it can only be triggered on the phone itself (i.e. not remotely) and a prominent notification should be shown as long as it’s enabled.
  • Carriers should offer users the ability to opt-out of having their stationary wireless devices entered in NEAD.
  • The FCC should ensure that NEAD and E911 data is used only for E911 purposes, and is never used for commercial purposes or shared with other government agencies without a warrant.
  • The FCC should also help users take back their location privacy by ensuring that any technology added to a phone to satisfy enhanced location regulations should only be used for non-911 purposes with the express opt-in consent of the user, on an app-by-app basis. This means that if carriers want to expose the output from things like barometric sensors or the names of nearby Wi-Fi networks to third-party apps, users should have the ability to decide for themselves whether or not they want to share that data with a given app.

Better 911 location accuracy has the potential to make a huge positive impact in peoples’ lives. But if people are concerned that this benefit will come at the expense of their privacy, they’re more likely to take steps that will prevent these location services from working properly. In order to prevent this, we need the FCC to make sure that privacy is baked in to new E911 regulations from the start. Otherwise, these rules may force people to choose between privacy and response time in an emergency, and that’s a decision nobody should have to make.

Read the whole story
1 day ago
"Without more specific guidelines, this could mean that carriers could use E911 regulations as an excuse to ubiquitously track the precise locations of all of their customers, both indoors and outdoors, all the time. Of course organizations like the NSA and DEA will likely demand access to that data, using the flimsy reasoning that such information is “only metadata.” " ... "we need the FCC to make sure that privacy is baked in to new E911 regulations from the start. Otherwise, these rules may force people to choose between privacy and response time in an emergency, and that’s a decision nobody should have to make"
Earth, Sol system, Western spiral arm
Share this story

Ask Slashdot: Best Medium For Personal Archive?

1 Comment
An anonymous reader writes What would be the best media to store a backup of important files in a lockbox? Like a lot of people we have a lot of important information on our computers, and have a lot of files that we don't want backed up in the cloud, but want to preserve. Everything from our personally ripped media, family pictures, important documents, etc.. We are considering BluRay, HDD, and SSD but wanted to ask the Slashdot community what they would do. So, in 2015, what technology (or technologies!) would you employ to best ensure your data's long-term survival? Where would you put that lockbox?
Read the whole story
1 day ago
There's no type of media you can put in a box with an expectation that in 50 years they can open it up and read it using a mass-market device.

There's no computer you can put in the box with it with an expectation that in 50 years anybody with electricity can boot the system up and use the media (just in case you thought of putting a raspberry pi or even a whole ipad in there, for instance).

Whatever you choose today, you'd better be reviewing it--probably more frequently than once per 5 years--for both integrity and availability of compatible hardware and software.

Make hardware choices that include redundancy (e.g., don't choose one SSD -- choose two different-chipset SSDs, or one SSD plus optical media; store them at different locations).

Make software choices that include openness (e.g., tar not only is a format standardized by POSIX, but there are currently multiple open source implementations of it), and ease of reverse engineering (e.g., the ppm image format could be reverse engineered in about half an hour) at the expense of stored size (i.e., don't use the hottest new compression format even to save 20% on file size) and featuritis (do you think somebody could ever write an independent implementation of zfs? choose ext2 or fat32, or tar)

And for small quantities of personal documents, please *PLEASE* use paper. Do the same for instructions regarding the format(s) of the digital data you've stored. If you use encryption, have a separate plan for documents that need to survive your own death.

Oh, and don't put 1000GB of "proof I'm a copyright infringer who planned to depend on a 'personal use' affirmative defense" in a bank vault.
Earth, Sol system, Western spiral arm
Share this story

Nibble Sort Programming Contest

1 Comment

The problem is to sort the 4-bit pieces of a 64-bit word with (unsigned) smaller values towards the small end of the word. The nibble sort of 0xbadbeef is 0xfeedbba000000000. The function you implement will perform this sorting operation on a buffer of 1024 64-bit integers:

void nibble_sort(unsigned long *buf); 

I’ll give a small prize to the submitter of the entry that performs this operation the fastest on my Core i7-4770. If the winner makes non-trivial use of SIMD, I’ll give a prize to that entry and also to the fastest non-SIMD entry. I’ll use GCC 4.9.2 to compile your C99 code, which may use SIMD intrinsics and also inline assembly if you choose. There’s no requirement for portability. The machine runs Ubuntu 14.04 in 64-bit mode. If you require any command line options other than “gcc -std=gnu99 -std=c99 -O3″ you need to tell me that. You may assume that the buffer starts at the start of a cache line. The buffer will be loaded with uniformly chosen random values. Submit code by emailing me. Submit entries before the end of January 2015.

Here’s a slow (but hopefully correct) reference implementation takes about 180 380 microseconds to do the job: for nibble-sorting a single word:

int read_nibble(unsigned long w, int i) {
  assert(i >= 0 && i < 16);
  unsigned long res = w >> (i * 4);
  return res & 0xf;

void write_nibble(unsigned long *w, int i, int v) {
  assert(i >= 0 && i < 16);
  unsigned long mask = 0xf;
  mask <<= (i * 4);
  *w &= ~mask;
  unsigned long prom = v;
  prom <<= (i * 4);
  *w |= prom;

unsigned long nibble_sort_word(unsigned nibble_sort(unsigned long arg) {
  for (int i = 0; i < 16; ++i) {
    int min = i;
    for (int j = i+1; j < 16; ++j) {
      if (read_nibble(arg, j) < read_nibble(arg, min))
        min = j;
    if (min != i) {
      int tmp = read_nibble(arg, i);
      write_nibble(&arg, i, read_nibble(arg, min));
      write_nibble(&arg, min, tmp);
  return arg;

 void nibble_sort(unsigned long *buf) {
  for (int i=0; i<1024; i++)
    buf[i] = nibble_sort_word(buf[i]);
Read the whole story
1 day ago
my entry uses counting sort. give it a try...
Earth, Sol system, Western spiral arm
Share this story
Next Page of Stories