Language Selection

English French German Italian Portuguese Spanish

Responsible Disclosure, and Amarok 1.4.10

Filed under
Software

Yesterday we released Amarok 1.4.10, an unanticipated security release. From the Release Anouncement you may notice that we gave thanks to Google Alerts for notifying us of this vulnerability. This was perfectly accurate.

I want to say up front that the security value of this vulnerability rates so low that it's amazing Secunia even bothered with it. It requires local access (or at least, a shell prompt), and it requires our code parsing a file whose name was hardcoded to execute the code (doesn't)/overflow a buffer (doesn't)/do things incorrectly (doesn't). At worst, you could maybe make Amarok crash, and since this would be a race condition, you'd have to be extremely lucky, and this could only happen between when the user was downloading the Magnatune database and when it was being parsed. Not exactly mission-critical. So, the actual threat of the vulnerability was approximately nil. That wasn't the driving factor behind the sudden release -- the driving factor was the fact that since Secunia did issue an advisory, we wanted to respond to it as soon as possible. Which should have been 36 hours before. Here's where the bungling comes in.

At midnight Tuesday morning, Dwayne Litzenberger posts a bug report on the public Debian bug tracker with snippets of code from Amarok, and the following:

I'm not familiar enough with Qt to be sure, but it looks to me like the code creating a temporary file insecurely. At minimum, I think this code will break if another user has already created /tmp/album_info.xml (thus preventing the current user from deleting it).

More Here




More in Tux Machines

Graphics: AMD, Intel and Vulkan

  • AMDGPU DC Fixes For Linux 4.17 Take Care Of "The Dark Screen Issue"
    AMD's Alex Deucher has sent in a small set of fixes for the AMDGPU Direct Rendering Manager driver in the Linux 4.17 kernel. The three patches are for fixing a dark screen issue with AMDGPU DC, a fix for clock/voltage dependency tracking for WattMan, and an updated SMU interface for the yet-to-be-announced Vega 12 GPU.
  • Intel KVMGT 2018-Q1 Release Offers Mediated GPU Pass-Through Improvements
    While the relevant bits for supporting Intel GPU mediated pass-through to virtual machines with KVM are now upstream in the Linux kernel as well as in QEMU 2.12, Intel developers have just announced their quarterly release of "KVMGT" for those wanting the officially blessed configuration for running Intel virtual GPU support with KVM virtual machines.
  • RADV Vulkan Driver Adds Vega M Support
    Following RadeonSI adding "Vega M" support for the new Radeon graphics appearing embedded on select Intel Kabylake processor packages, the RADV developers have similarly staged their Vega M support in this open-source Vulkan driver.
  • The Forge Now Offers Full-Featured Vulkan Support On Linux
    Earlier this month we covered "The Forge" picking up initial Linux support and now they have rounded out their full-featured Linux support with Vulkan rendering.

Games Leftovers

Red Hat Rebranding and Shares

Databases: Revenue Shift and PostgreSQL

  • How open source databases are sucking revenue out of legacy vendors’ pockets
    In other words, the value of the open source database market to customers/users is measured in the tens of billions, or even hundreds of billions, of dollars. One other way of thinking about this? That's tens or hundreds of billions of dollars that proprietary vendors will never capture.
  • Has the time finally come for PostgreSQL?
    For nearly 30 years, PostgreSQL (a.k.a., Postgres) has arguably been the most common SQL open source database that you have never heard of. Call it the Zelig of databases, its technology either sat behind or acted as the starting point behind an array of nearly a dozen commercial database offerings from EnterpriseDB to Redshift, Greenplum, Netezza, CockroachDB and a host of others. And PostgreSQL has distinguished lineage as one of the brainchilds of Turing Award winner and database legend Dr. Michael Stonebraker, who started the PostgreSQL project based on the lessons learned from his previous database venture, Ingres.