Easier and more secure browsing in Tor Browser 4.5

The Tor project released a new version of the Tor Browser on April 27, updating many of the browser's built-in tools and improving the network-security layer. Tor Browser provides a more convenient way for users to use the anonymity and privacy of a Tor connection for their web browsing: the browser bundle is a portable application that can be run from anywhere and does not require a working Tor software installation to be installed on the host machine.

The Tor Browser, as always, is derived from Mozilla Firefox. The 4.5 release is based on Firefox 31.6 with several later patches backported—most notably, certificate-pinning improvements from Firefox 32 and 33. It also includes the Firefox extensions NoScript (version 2.6.9.22) and HTTPS Everywhere (version 5.0.3), and it bundles in the Tor client (version 0.2.6.7) and several of Tor's pluggable transport modules. These transports are plugins that obfuscate the traffic between a Tor client and the entrance node to a Tor circuit, thus making it more difficult for censors to block Tor usage. Downloads are available in a variety of language and locale options for most major operating systems.

The binaries available for download are verifiable builds; signed hashes of each binary are provided, which can be used to verify that independent builds produce the same hash. Any builder can follow the build instructions and check that their build's hash matches the official packages, and users can compare signed hashes from a number of developers' keys. This feature was introduced in the Tor Browser 3.0 series; 4.5 takes the verifiable-build concept a bit further by introducing verifiable incremental-update files as well. There are Mozilla Archive (MAR) files available for updating most 4.0-series Tor Browser binaries to 4.5, and those update files now include hash signatures as well.

Quite a bit of work has clearly gone into making Tor Browser 4.5 better on the usability front. This starts with the wrapper script used to start the browser itself. Because Tor Browser is a self-contained bundle, previous releases tended to fare rather poorly on system integration—the package was not available in the "Applications" menu, for instance, and users were left to create their own launcher scripts if they wanted the browser to appear in their PATH. As of 4.5, when Tor Browser is run for the first time, it is through a "setup" wrapper that correctly configures the user's Tor connection and, on Linux, customizes a .desktop application launcher file. This launcher can be called from any Freedesktop.org-compliant menu system or panel, run from the file manager, or even executed from the command line.

Another new usability feature is a revamped "onion menu" in the browser's main toolbar. This menu provides access to Tor- and security-related settings and features. Clicking on the menu's icon now displays status information about the Tor circuit in use for the current connection—akin to the SSL/TLS site-certificate information that Firefox displays when clicking on the location bar's lock icon. The menu also allows the user to initiate a new Tor circuit for the current page.

The settings accessible from the onion menu include a new "security slider" that allows the user to adjust the browser's overall security settings with one action. The "Low" setting (which is the default) provides basic anonymity and privacy via Tor, but does not disable any general-purpose browser features. The "Medium Low" setting turns all HTML5 video and audio content into click-to-play elements, blocks remote Java applets, disables MathML support, and disables some JavaScript performance-optimization techniques (specifically, the IonMonkey just-in-time (JIT) compiler, type inference, and asm.js) with NoScript.

In addition to the other settings, "Medium High" also disables the Baseline JavaScript JIT, disables SVG OpenType rendering and Graphite font-rendering, and disables all JavaScript on non-HTTPS sites. The "High" setting additionally disables JavaScript on HTTPS sites (although it can be re-enabled on a site-by-site basis), disables SVG rendering, and disables CSS web fonts.

Some of the features disabled with the security slider have clear security risks (such as executing remote Java applets), while others are disabled because the techniques involved have a high incidence of historical security vulnerabilities. The announcement notes that the project gleans such historical vulnerability information from research by iSEC Partners.

Under the hood, Tor Browser 4.5 offers some key improvements to the way site traffic is managed. All requests initiated in a tab will be restricted to the same Tor circuit. That should prevent problems like having a site's language suddenly change because one HTTP request is sent over a Tor circuit different than the one used a few minutes earlier.

The browser also isolates sites from one another by ensuring that different pages' requests travel over different circuits, even when those requests are to third-party sites. This ensures that embedded elements like the pervasive "like" buttons placed by social-media services cannot track the user between pages loaded in different tabs. Furthermore, the URL.createObjectURL() method from the W3C File API (a method that can be used by JavaScript code to create a new URL reference) is restricted to the same circuit as the page that called it and the SharedWorker API has been disabled entirely. Both methods could be abused to enable cross-site communication and, thus, to allow sites to track the user across multiple web sites.

Other privacy enhancements include the disabling of the W3C Sensor API and the Mozilla video statistics API (both of which enable a site to record information about the browser's behavior) and a new default search engine. The new search engine, Disconnect, is a privacy-conscious search redirector that is maintained by a privately funded US security start-up; it sends the user's search queries to popular search engines like Google, both anonymizing the request and sanitizing the results returned by the downstream search provider.

Last but not least, the new browser release includes rewritten transport modules and introduces a new transport called obfs4. The obfs4 transport is designed to better resist deep-packet inspection (DPI); the 4.5 release announcement notes that obfs4 currently enables Tor access from within China. Recent Tor releases include obfs4 (so it is running on up-to-date bridge nodes), but clients need to have the package, too, in order to use it as a transport.

If censors learn the IP address of a Tor bridge node, they can block access to that node, but it is believed that an obfs4-powered node cannot be discovered through any known automated traffic-scanning techniques. For such a bridge node to be revealed, it would have to be discovered and reported through some other means.

On the whole, the changes in Tor Browser 4.5 make for an easier-to-configure browsing experience, which is critical for convincing users to give it a chance. The lower-level improvements like better circuit isolation and improved transports may not be visible to the casual user, but are certainly critical. Given that the state of the art changes so rapidly on the web, it is encouraging to see Tor Browser keeping pace.

Comments (none posted)

The programming talent myth

Jacob Kaplan-Moss is known for his work on Django but, as he would describe in his PyCon 2015 keynote, many think he had more to do with its creation than he actually did. While his talk ranged quite a bit, the theme covered something that software development organizations—and open source projects—may be grappling with: a myth about developer performance and how it impacts the industry. It was a thought-provoking talk that was frequently punctuated by applause; these are the kinds of issues that the Python community tries to confront head on, so the talk was aimed well.

Some background

Kaplan-Moss began by noting that he is a contributor to Django and the director of security at Heroku. He is a longtime PyCon attendee (eleven years) as well as a regular speaker at the conference (ten years). The Python community means "more to me than anything in tech" and giving a keynote at PyCon is "the highlight of my career", he said.

His first PyCon talk was in 2005 about a utility for bridging Python and AppleScript. At the same PyCon, which was held in Washington, DC, Adrian Holovaty gave a tech demo of some tools that were being used to build web sites at the newspaper in Lawrence, Kansas where they both worked. Those tools are what became Django. Now Django is ten years old and is used around the world, he said. He has watched PyCon go from 300 people to nearly 3000 and the community explode with new people and growing diversity. So "I really mean it" that the keynote is "the apex of my professional career".

On the other hand, though, his main emotion there on the stage was insecurity. There is a voice that is telling him he does not belong on the stage with the others he has shared it with; that he doesn't deserve the success he has had. There is "a little hater" (in the words of Jay Smooth from a video clip that Kaplan-Moss played) in the back of his head telling him these things.

The "really insidious thing" about the little hater is that a little bit of what he says is right. That is not a "humble brag" or false modesty on his part, he said, and there are things he has done that he is "incredibly proud of". In fact, there are things that he has done that do make him feel qualified to be on that stage, but they are probably not the things that the audience is thinking about.

Many probably think he is giving a keynote because he is the "inventor of Django", but that isn't at all the case. Those who know a bit more about how Django came to be might think of him as the "co-creator of Django", but even that overstates things significantly. He was actually hired to work at the newspaper a year after Holovaty and Simon Willison invented and co-created Django. "Really, I'm the guy who got hired to work on the thing a year after it was already made", he said with a grin.

People assume that he is somehow responsible for the creation of Django because he is an "incredible programmer"; that he is a "rock star" or a "ninja" programmer—or "whatever it is that recruiters are calling it these days". People believe that he is successful because of his programming skill. But that simply isn't true: "I am, at best, an average programmer", he said (with a slide that read "Hi, I'm Jacob, and I'm a mediocre programmer.").

Running

He switched gears a bit, putting up a picture of ultramarathon runner Ann Trason, who is the most accomplished competitor in the history of that sport. Ultramarathons are runs that are longer than the 26 miles of a marathon; typically they are run on trails requiring stream crossings and the hardest races can take multiple days of continuous running to complete. Distances for races are generally 50-160km. Trason has set multiple course records that still stand 10 or 20 years later. No one has come within an hour of some of her records, he said. It is hard to overstate how dominant and how exceptional Trason has been in that sport. He was talking about that because he recently finished his first 50km race, which means he can call himself an ultra runner too.

He is, however, not anywhere close to Trason's league, but he does get to wear the same label. He is a mediocre runner, finishing 535th out of around 1000. There are lots of numbers that can be used to quantify his performance: his pace, the distance and elevation change of the course, and so on. There is a site that calculates a "runner's score" that estimates how close a runner's time will be to that of the winner of the race. He is around 68% (which overstates things, he said), while Trason is 98.58% ("in other words, she usually wins").

That gap is not particularly surprising. If you plot a histogram of times in a race (or runner's scores, etc.), you get a familiar curve: the bell curve or the normal distribution. Most people are average, while there are a few that are either exceptionally good or bad in "the skinny ends of the curve". Almost every skill that we know how to measure ends up showing a distribution that looks like that curve.

Mediocrity

When he said that he was a mediocre programmer, some in the audience probably didn't believe him, he said. Why is that? The vast majority of those in the audience have never actually worked with Kaplan-Moss, so why would they assume his coding ability is exceptional? In the absence of any other data, people should assume that he is solidly in the middle of the curve. Part of the problem there is the lack of a way to even measure coding ability. "We are infants in figuring out how to measure our ability to produce software", he said. What are our metrics? Lines of code—what does that measure? Story points? "What even is a story point?", he wondered.

Programmers like to think they work in a field that is logical and analytical, but the truth is that there is no way to even talk about programming ability in a systematic way. When humans don't have any data, they make up stories, but those stories are simplistic and stereotyped. So, we say that people "suck at programming" or that they "rock at programming", without leaving any room for those in between. Everyone is either an amazing programmer or "a worthless use of a seat".

But that would mean that programming skill is somehow distributed on a U-shaped curve. Most people are at one end or the other, which doesn't make much sense. Presumably, people learn throughout their careers, so how would they go from absolutely terrible to wonderful without traversing the middle ground? Since there are only two narratives possible, that is why most people would place him in the "amazing programmer" bucket. He is associated with Django, which makes the crappy programmer label unlikely, so people naturally choose the other.

But, if you could measure programming ability somehow, its curve would look like the normal distribution. Most people are average at most things. This is not Lake Wobegon, most people are not above average, he said.

A dangerous myth

This belief that programming ability fits into a bi-modal distribution (i.e. U-shaped) is both "dangerous and a myth". This myth sets up a world where you can only program if you are a rock star or a ninja. It is actively harmful in that is keeping people from learning programming, driving people out of programming, and it is preventing "most of the growth and the improvement we'd like to see", he said to a big round of applause.

The US Bureau of Labor Statistics estimates that by 2020 there will be a 1.5 million programming job gap, which means there will be that many jobs unfilled. That's in five years. The EU has published similar numbers, 1.2 million in 2018—three years. That means we need to be doing something to get more people into our industry. But the myth is a filter that prevents people from even considering programming as a career. The myth is aided by the belief that programming is an innate talent that people are born with. Those who do not know how to write software and who believe in the myth fall into a trap: thinking that their age has reached "30 or 20 or 15" (or even 40 or 60, he added later) and, because they haven't written any code yet, that means that they never can or will.

If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again. That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.

But we don't believe these things about other activities. Over half a million people ran a marathon last year—did all of them have an innate talent for running? Kaplan-Moss doubts that they did; he didn't. Most of those people ran their marathon rather badly, but a tiny fraction ran theirs very fast. To be a runner, though, all it takes is a pair of shoes. We don't even believe that you have to particularly like running to be a runner.

Someone asked him what the best part of running the 50km race was; "finishing" was his answer. Running a marathon is difficult; it takes lots of training and requires commitment and focus. Is writing software—writing Python—harder than running a marathon? "Why aren't there half a million people here today?", he asked. We tell ourselves different stories about one skill, coding, than we do for another, running.

He then gave an example of what this narrative can do to people. At the University of Kansas's geographic information system (GIS) day a few years ago, he sat in on a "fantastic presentation" about predicting seasonal floods on the Kansas River. The student had used tools that should be familiar to many of those at PyCon: Amazon Web Services, Linux, PostgreSQL, Python, Django, GeoDjango, and so on. Kaplan-Moss was hiring at the time, and she (the student) had just written thousands of lines of Python, so he asked if she wanted to interview for his company. Her response was that she couldn't do that, because she "was not really a programmer". That came from a woman who had just invented her own distributed GIS data processing pipeline, he said—but she's not really a programmer. That's because "programming is something you are in this myth, not something you do".

Just skills to be learned

The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. Programming isn't even one thing, though he had been talking about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. Also, "we need to have at least one person who understands Unicode", he said to laughter.

There are multiple independent skills, but we tend to assume that someone is the minimum of their skill set. Sure, you might be a good designer, speak and write well, and be a great project manager, but you don't know how a linked list works, so "get out of the building". Like any other skill, you can program professionally, occasionally, or as a hobby, as a part-time job or a full-time job. You can program badly, program well, or, most likely, be an average programmer.

If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers. If the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. Even once we get people into the community, the talent myth can haunt them—it can actively drive people out of tech.

The tech industry is rife with sexism, racism, homophobia, and discrimination. It is a multi-faceted problem, and there isn't a single cause, but the talent myth is part of the problem. In our industry, we recast the talent myth as "the myth of the brilliant asshole", he said. This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?

At that point, he added the famous picture of Linus Torvalds flipping off NVIDIA under the "brilliant asshole" label in his slide. While some might argue the context, it certainly struck a chord for the people at the keynote as it was met with laughter and applause.

"Real programmers"

Kaplan-Moss then asked what a 10x programmer looked like and put up a series of pictures of "Mark Zuckerberg". The first was actually the actor who played Zuckerberg in The Social Network movie, while the second was the Saturday Night Live cast member who satirized the actor in the movie. The third actually was Zuckerberg. All three were young white men, which is the archetype of a "real programmer", he said.

When we see someone who does not look like one of those three men, we assume they are not a real programmer, he said. Almost all of the women he knows in the industry have a story about someone assuming they aren't a programmer. He talked to multiple women attending PyCon 2015 who were asked which guy they are there with—the only reason they would come is because their partner, the man, is the programmer. "If you're a dude, has anyone ever asked you that?"

On the other hand, when he got up on stage, he did look like those guys. "So you probably assumed I was a real programmer." These sorts of assumptions contribute to the attrition of marginalized people in tech, he said.

He presented some numbers from the National Center for Women & Information Technology (NCWIT). Half of women with Computer Science degrees are not using those degrees as part of their employment. 40% of women leave technology within ten years, while only 17% of men do. Over half of women leave the industry at the mid-point of their careers.

There are certainly other causes, he said, and wasn't implying that there is only one root cause. But imagine how frustrating it must be to be a woman with a decade of experience and have someone assume that she doesn't know what she is talking about. It is going to take a serious effort to overcome the diversity problem. We are never going to get there if we can't come up with a more nuanced way to think about what a programmer is—and what programming skills really are.

There are all kinds of runners—sprinters, distance runners, marathoners, etc.—of all shapes, sizes, genders, ages, and races. All of them have different metrics for success and all are capable of being successful by their own metrics. "We have got to find such a nuanced, shaded, interesting way of thinking about skill in tech," he said.

A conversation with Lynn Root at PyCon a number of years ago was the genesis for his talk. Root is a programmer, a founder of the San Francisco chapter of PyLadies, a Python Software Foundation board member, and has "been in and around this community for a while". PyLadies was fairly new at the time of the conversation and he was excited about the energy, excitement, people, and skills that the group was bringing to the table. To Root he said "it's so great to see all of these bad-ass women programmers". She agreed, but noted: "We'll know we've been really successful when there are a whole bunch of average women programmers". That too, was met with big applause.

The talent myth sets an "impossibly high bar for entry", he said, and the fact that any of us are here at all "is kind of shocking given this myth". It needs to be dismantled and a community that recognizes that "average is actually pretty awesome" should be be built in its place. He is a mediocre programmer and he invited others to join him; "together we can do our jobs perfectly adequately". Attendees gave Kaplan-Moss a standing ovation for the keynote.

After that, he took questions, but he requested that people actually ask questions, rather than to use the microphone as a way to "share their opinion or to pontificate on what the speaker has said". He said that he is personally quite interested to hear those opinions, but that it should be done in email or on Twitter, because sitting in the audience during these "non-questions" leads to "frustration and anger". Based on the applause for that, he is not the only one to be annoyed by that behavior.

Several questioners also admitted to mediocrity in programming. Questions ranged from whether the security field is different with regard to the talent myth (short answer, it is "even worse", which makes it that much harder for people to enter that field), myths around the depth vs. breadth of knowledge (it is part of the myth that people have to "impossibly know everything about everything", there are roles for both specialists and generalists), and how to get mediocre programmers to get the courage to apply for these jobs ("I wish I knew the answer to that").

Perhaps the question he spent the most time answering was how to get these ideas into the heads of the recruiters, venture capitalists, and others who are actually determining who gets brought into the community. It is a difficult question to answer, he said. Part of it has to do with the "crazy 60-hour weeks" that have come to be expected. Companies need to respect the idea of a work-life balance, with work weeks of 40 or 35 hours, and it is up to those who are in prominent positions to push their companies to recognize that. People should be able to do their jobs well, adequately, that is, and be commended for that. The same goes for working a healthy schedule—it should be commended as well. With a 1.5 million job gap looming, companies that don't do so may find themselves unable to fill the positions that they have.

[A YouTube video of the keynote is available.]

Comments (146 posted)

Random numbers from CPU execution time jitter

Availability of entropy, especially for embedded devices early in the kernel boot process, is a commonly discussed problem in the kernel random number community. The usual sources of entropy depend on events like the timing of user input or disk interrupts that may not be present yet—or at all. A patch set from Stephan Müller seeks to remedy that by using entropy that is collected from a source that is always present: CPU execution time jitter.

On a modern processor, there are many different factors that can impact the amount of time it takes to execute the same set of instructions. If one measures that execution time precisely multiple times, it will show variation—jitter. An attacker who doesn't have any special hardware-level access to the CPU cannot predict this jitter, which makes it a good source of entropy, according to Müller's lengthy paper on the technique.

There are numerous CPU-level activities that lead to unpredictability in execution time. The fill level of the instruction pipelines, memory wait states, instruction and data caches, branch prediction, interrupts, power management, frequency scaling, and so on can all contribute to changing the execution time. As Müller's paper shows, a wide variety of today's processors show enough jitter (in a statistical sense) to be used as an entropy source for the kernel's random number pools.

The heart of the algorithm to implement Müller's jitter measurement gathering lives in the jent_measure_jitter() function. It is effectively a "random bit generator", since it returns a single bit that has been calculated based on the jitter measured in that function. The first step is to introduce some noise into the measurement based on memory reads and writes. The jitter entropy module allocates a 2KB buffer during initialization that it loops through and simply adds one to the value stored there (which causes both a load and a store). The buffer is larger than the L1 cache of the processor, which should introduce some unpredictable wait states into the measurement.

It then gets a timestamp and calculates a delta from the previous timestamp. This delta is used in a "deliberately inefficient" calculation to fold the value down to a single bit. There are faster ways to do the folding operation, but his algorithm is part of what is being measured for jitter in the execution time. In order to preserve those measurements, optimization for the jitter random number generator (RNG) must be turned off. In fact, there is a test in the code that will cause the build to fail if optimization is enabled to avoid the possibility of getting bad random numbers from a misconfigured build. The comment for the jent_fold_time() function explains a bit further:

The jent_gen_entropy() function generates a 64-bit random number by calling jent_measure_jitter() 64 times. Getting larger amounts of random data is done with jent_read_entropy(), which takes a buffer and length and repeatedly calls jent_gen_entropy() to fill the buffer with the requested amount of random data.

Adding the CPU jitter RNG is only part of what the patch set does, however. The kernel's deterministic random bit generator (DRBG) is currently initialized by making a call to get_random_bytes(), which uses the non-blocking random number pool. In certain circumstances (e.g. for some embedded devices or virtual machines), that pool will not have been seeded from enough events to provide the entropy required.

In mid-April, kernel crypto subsystem maintainer Herbert Xu asked Müller whether the current DRBG implementation was compliant with the US National Institute of Standards and Technology (NIST) SP 800-90A specification for DRBGs that specifies seeding DRBGs from non-deterministic sources. Since the worst case for get_random_bytes() is that it is completely deterministic, Xu felt that some other mechanism should be used to seed the kernel's DRBG so that it complied.

Müller had already proposed inclusion of his CPU jitter RNG in October 2013. He used that code as the basis for this new patch set. Instead of reusing the existing blocking pool (i.e. the one that feeds /dev/random), though, his patch creates a new kernel_pool that is only accessible to the kernel itself. That eliminates a kind of denial-of-service attack where a user-space program can continuously read /dev/random to consume all of the entropy being generated by the system.

The DRBG is then seeded early in the boot process from a combination of get_random_bytes() and the jitter RNG. In addition, an asynchronous call is made for the required amount of random data from the new, blocking kernel_pool. It will only return once the required amount of entropy has been gathered by the system and the random data returned will be used to reseed the DRBG. Thus, the DRBG is always seeded with non-deterministic data early on—as long as the jitter RNG is actually producing random numbers.

Back in 2013, kernel RNG maintainer Ted Ts'o expressed skepticism about the jitter technique. He was concerned that the measurements were not as unpredictable as they appear to be—that a sufficiently knowledgeable attacker could determine enough of the state to predict the timing.

Effectively, he was worried that the entropy estimation for the jitter measurements was too high, perhaps far too high.

Ts'o has not commented on the latest patches, at least yet. In fact, there haven't really been any technical comments on the patches as yet. Xu seemed to indicate that he is generally in favor of Müller's solution for the DRBG. If the patches do get merged, perhaps other users for the jitter RNG will emerge. It is a fairly straightforward and speedy mechanism for collecting entropy—the question is how much of that entropy is "real".

Comments (35 posted)

Security quotes of the week

— Erich Schubert (Thanks to Paul Wise.)

— Bruce Schneier

— Paul Vixie

Comments (6 posted)

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Ars Technica reports on a wpa_supplicant bug that might leave Linux and other systems open to remote code execution. "That's because the code fails to check the length of incoming SSID information and writes information beyond the valid 32 octets of data to memory beyond the range it was allocated. SSID information 'is transmitted in an element that has a 8-bit length field and potential maximum payload length of 255 octets,' [wpa_supplicant maintainer Jouni] Malinen wrote, and the code 'was not sufficiently verifying the payload length on one of the code paths using the SSID received from a peer device. This can result in copying arbitrary data from an attacker to a fixed length buffer of 32 bytes (i.e., a possible overflow of up to 223 bytes). The overflow can override a couple of variables in the struct, including a pointer that gets freed. In addition, about 150 bytes (the exact length depending on architecture) can be written beyond the end of the heap allocation.'"

Comments (32 posted)

389-ds-base: access control bypass

Package(s):	389-ds-base	CVE #(s):	CVE-2015-1854
Created:	April 29, 2015	Updated:	May 4, 2015
Description:	From the Red Hat advisory: A flaw was found in the way Red Hat Directory Server performed authorization of modrdn operations. An unauthenticated attacker able to issue an ldapmodrdn call to the directory server could use this flaw to perform unauthorized modifications of entries in the directory server. (CVE-2015-1854)
Alerts:	Mageia MGASA-2015-0183 389-ds-base 2015-05-03 Scientific Linux SLSA-2015:0895-1 389-ds-base 2015-04-30 CentOS CESA-2015:0895 389-ds-base 2015-04-28 Oracle ELSA-2015-0895 389-ds-base 2015-04-28

Comments (none posted)

cherokee: authentication bypass

Package(s):	cherokee	CVE #(s):	CVE-2014-4668
Created:	April 27, 2015	Updated:	May 5, 2015
Description:	From the CVE entry: The cherokee_validator_ldap_check function in validator_ldap.c in Cherokee 1.2.103 and earlier, when LDAP is used, does not properly consider unauthenticated-bind semantics, which allows remote attackers to bypass authentication via an empty password.
Alerts:	Mandriva MDVSA-2015:225 cherokee 2015-05-04 Mageia MGASA-2015-0181 cherokee 2015-05-03 Fedora FEDORA-2015-6279 cherokee 2015-04-27 Fedora FEDORA-2015-6392 cherokee 2015-04-27

Comments (none posted)

chromium: multiple vulnerabilities

Package(s):	chromium	CVE #(s):	CVE-2015-1243 CVE-2015-1250
Created:	April 29, 2015	Updated:	May 12, 2015
Description:	From the Arch Linux advisory: - CVE-2015-1243 (use-after-free): Use-after-free in DOM. Credit to Saif El-Sherei. - CVE-2015-1250: Various fixes from internal audits, fuzzing and other initiatives.
Alerts:	Gentoo 201506-04 chromium 2015-06-22 openSUSE openSUSE-SU-2015:0853-1 Chromium 2015-05-12 Ubuntu USN-2582-1 oxide-qt 2015-05-06 Mageia MGASA-2015-0182 chromium-browser-stable 2015-05-03 Debian DSA-3242-1 chromium-browser 2015-05-01 Red Hat RHSA-2015:0921-01 chromium-browser 2015-04-30 Arch Linux ASA-201504-30 chromium 2015-04-29

Comments (none posted)

dovecot: denial of service

Package(s):	dovecot	CVE #(s):	CVE-2015-3420
Created:	April 29, 2015	Updated:	May 20, 2015
Description:	From the Arch Linux advisory: Dovecot <= 2.2.14 does not correctly handle SSL/TLS handshake failure in the login process, asking OpenSSL to flush a connection that has already been aborted. This results in a crash with some versions of OpenSSL (most likely >= 1.0.2).
Alerts:	Arch Linux ASA-201504-31 dovecot 2015-04-29 Fedora FEDORA-2015-7159 dovecot 2015-05-19 Fedora FEDORA-2015-7089 dovecot 2015-05-19

Comments (none posted)

kernel: denial of service

Package(s):	kernel	CVE #(s):	CVE-2015-2922
Created:	April 23, 2015	Updated:	July 16, 2015
Description:	From the Red Hat bugzilla entry: Linux kernel built with the IPv6 networking support(CONFIG_IPV6) is vulnerable to setting its 'hop_limit' too low, via the neighbour discovery protocol. It could result in thwarting the IPv6 functionality. An unprivileged user on a local network could use this flaw to cause DoS to a remote system.
Alerts:	openSUSE openSUSE-SU-2016:0301-1 kernel 2016-02-01 Oracle ELSA-2015-2152 kernel 2015-11-25 openSUSE openSUSE-SU-2015:1382-1 kernel 2015-08-14 SUSE SUSE-SU-2015:1376-1 kernel-rt 2015-08-12 Scientific Linux SLSA-2015:1534-1 kernel 2015-08-06 CentOS CESA-2015:1534 kernel 2015-08-06 Red Hat RHSA-2015:1564-01 kernel-rt 2015-08-05 Red Hat RHSA-2015:1565-01 kernel-rt 2015-08-05 Red Hat RHSA-2015:1534-01 kernel 2015-08-05 Oracle ELSA-2015-3064 kernel 3.8.13 2015-07-31 Oracle ELSA-2015-3064 kernel 3.8.13 2015-07-31 SUSE SUSE-SU-2015:1478-1 kernel 2015-09-02 Scientific Linux SLSA-2015:1221-1 kernel 2015-07-15 Oracle ELSA-2015-3050 kernel 2.6.32 2015-07-16 Oracle ELSA-2015-3050 kernel 2.6.32 2015-07-16 Oracle ELSA-2015-3049 kernel 2.6.39 2015-07-16 Oracle ELSA-2015-3049 kernel 2.6.39 2015-07-16 Oracle ELSA-2015-3048 kernel 3.8.13 2015-07-15 Oracle ELSA-2015-3048 kernel 3.8.13 2015-07-15 CentOS CESA-2015:1221 kernel 2015-07-15 Red Hat RHSA-2015:1221-01 kernel 2015-07-14 SUSE SUSE-SU-2015:1224-1 kernel 2015-07-10 Debian-LTS DLA-246-1 linux-2.6 2015-06-17 Ubuntu USN-2586-1 linux-ti-omap4 2015-04-30 Ubuntu USN-2589-1 linux-lts-utopic 2015-04-30 Ubuntu USN-2587-1 linux-lts-trusty 2015-04-30 Ubuntu USN-2585-1 kernel 2015-04-30 Ubuntu USN-2588-1 kernel 2015-04-30 Ubuntu USN-2590-1 kernel 2015-04-30 Debian DSA-3237-1 kernel 2015-04-26 Fedora FEDORA-2015-6294 kernel 2015-04-22 Fedora FEDORA-2015-6320 kernel 2015-04-22 SUSE SUSE-SU-2015:1071-1 kernel 2015-06-16 Debian-LTS DLA-246-2 linux-2.6 2015-06-17

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2014-9715 CVE-2015-2830 CVE-2015-3331 CVE-2015-3332 CVE-2015-3339
Created:	April 27, 2015	Updated:	July 30, 2015
Description:	From the Debian advisory: CVE-2014-9715: It was found that the netfilter connection tracking subsystem used too small a type as an offset within each connection's data structure, following a bug fix in Linux 3.2.33 and 3.6. In some configurations, this would lead to memory corruption and crashes (even without malicious traffic). This could potentially also result in violation of the netfilter policy or remote code execution. This can be mitigated by disabling connection tracking accounting: sysctl net.netfilter.nf_conntrack_acct=0 CVE-2015-2830: Andrew Lutomirski discovered that when a 64-bit task on an amd64 kernel makes a fork(2) or clone(2) system call using int $0x80, the 32-bit compatibility flag is set (correctly) but is not cleared on return. As a result, both seccomp and audit will misinterpret the following system call by the task(s), possibly leading to a violation of security policy. CVE-2015-3331: Stephan Mueller discovered that the optimised implementation of RFC4106 GCM for x86 processors that support AESNI miscalculated buffer addresses in some cases. If an IPsec tunnel is configured to use this mode (also known as AES-GCM-ESP) this can lead to memory corruption and crashes (even without malicious traffic). This could potentially also result in remote code execution. CVE-2015-3332: Ben Hutchings discovered that the TCP Fast Open feature regressed in Linux 3.16.7-ckt9, resulting in a kernel BUG when it is used. This can be used as a local denial of service. CVE-2015-3339: It was found that the execve(2) system call can race with inode attribute changes made by chown(2). Although chown(2) clears the setuid/setgid bits of a file if it changes the respective owner ID, this race condition could result in execve(2) setting effective uid/gid to the new owner ID, a privilege escalation.
Alerts:	openSUSE openSUSE-SU-2016:2649-1 kernel 2016-10-26 SUSE SUSE-SU-2016:2074-1 kernel 2016-08-15 openSUSE openSUSE-SU-2016:0301-1 kernel 2016-02-01 Scientific Linux SLSA-2015:2152-2 kernel 2015-12-21 Oracle ELSA-2015-2152 kernel 2015-11-25 Red Hat RHSA-2015:2411-01 kernel-rt 2015-11-19 Red Hat RHSA-2015:2152-02 kernel 2015-11-19 SUSE SUSE-SU-2015:1611-1 kernel 2015-09-23 SUSE SUSE-SU-2015:1592-1 kernel 2015-09-22 openSUSE openSUSE-SU-2015:1382-1 kernel 2015-08-14 SUSE SUSE-SU-2015:1376-1 kernel-rt 2015-08-12 Oracle ELSA-2015-3068 kernel 2.6.32 2015-08-06 Oracle ELSA-2015-3068 kernel 2.6.32 2015-08-06 Oracle ELSA-2015-3067 kernel 2.6.39 2015-08-06 Oracle ELSA-2015-3067 kernel 2.6.39 2015-08-06 Scientific Linux SLSA-2015:1534-1 kernel 2015-08-06 CentOS CESA-2015:1534 kernel 2015-08-06 Red Hat RHSA-2015:1564-01 kernel-rt 2015-08-05 Red Hat RHSA-2015:1565-01 kernel-rt 2015-08-05 Red Hat RHSA-2015:1534-01 kernel 2015-08-05 Scientific Linux SLSA-2015:1272-1 kernel 2015-08-03 Oracle ELSA-2015-3064 kernel 3.8.13 2015-07-31 Oracle ELSA-2015-3064 kernel 3.8.13 2015-07-31 Oracle ELSA-2015-3055 kernel 2.6.32 2015-08-01 Oracle ELSA-2015-3055 kernel 2.6.32 2015-08-01 Oracle ELSA-2015-3054 kernel 2.6.39 2015-08-01 Oracle ELSA-2015-3054 kernel 2.6.39 2015-08-01 SUSE SUSE-SU-2015:1491-1 kernel 2015-09-04 SUSE SUSE-SU-2015:1488-1 kernel 2015-09-04 SUSE SUSE-SU-2015:1478-1 kernel 2015-09-02 Oracle ELSA-2015-3053 kernel 3.8.13 2015-07-29 Oracle ELSA-2015-3053 kernel 3.8.13 2015-07-29 Oracle ELSA-2015-1272 kernel 2015-07-29 SUSE SUSE-SU-2015:1489-1 kernel 2015-09-04 Red Hat RHSA-2015:1272-01 kernel 2015-07-22 SUSE SUSE-SU-2015:1487-1 kernel 2015-09-04 Scientific Linux SLSA-2015:1221-1 kernel 2015-07-15 CentOS CESA-2015:1221 kernel 2015-07-15 Oracle ELSA-2015-1221 kernel 2015-07-14 Red Hat RHSA-2015:1221-01 kernel 2015-07-14 Red Hat RHSA-2015:1199-01 kernel 2015-06-30 Scientific Linux SLSA-2015:1137-1 kernel 2015-06-25 Oracle ELSA-2015-3047 kernel 2015-06-25 Oracle ELSA-2015-3047 kernel 2015-06-25 Oracle ELSA-2015-3045 kernel 2015-06-24 Oracle ELSA-2015-3045 kernel 2015-06-24 Oracle ELSA-2015-3046 kernel 2015-06-24 Oracle ELSA-2015-3046 kernel 2015-06-24 Oracle ELSA-2015-1137 kernel 2015-06-23 CentOS CESA-2015:1137 kernel 2015-06-24 Red Hat RHSA-2015:1138-01 kernel-rt 2015-06-23 Red Hat RHSA-2015:1139-01 kernel-rt 2015-06-23 Red Hat RHSA-2015:1137-01 kernel 2015-06-23 CentOS CESA-2015:1081 kernel 2015-06-10 Scientific Linux SLSA-2015:1081-1 kernel 2015-06-09 Oracle ELSA-2015-1081 kernel 2015-06-09 Red Hat RHSA-2015:1081-01 kernel 2015-06-09 Scientific Linux SLSA-2015:0987-1 kernel 2015-05-13 Oracle ELSA-2015-3035 kernel 2015-05-13 Oracle ELSA-2015-3035 kernel 2015-05-13 Oracle ELSA-2015-3036 kernel 2015-05-13 Oracle ELSA-2015-3036 kernel 2015-05-13 Mageia MGASA-2015-0219 kernel-tmb 2015-05-13 CentOS CESA-2015:0987 kernel 2015-05-13 Oracle ELSA-2015-0987 kernel 2015-05-12 Fedora FEDORA-2015-7736 kernel 2015-05-12 Red Hat RHSA-2015:0989-01 kernel-rt 2015-05-12 Red Hat RHSA-2015:0981-01 kernel-rt 2015-05-12 Red Hat RHSA-2015:0987-01 kernel 2015-05-12 Ubuntu USN-2600-2 kernel 2015-05-08 Ubuntu USN-2597-2 linux-lts-trusty 2015-05-08 Ubuntu USN-2599-2 linux-lts-utopic 2015-05-08 Ubuntu USN-2598-2 kernel 2015-05-08 Ubuntu USN-2599-1 linux-lts-utopic 2015-05-05 Ubuntu USN-2597-1 linux-lts-trusty 2015-05-05 Ubuntu USN-2596-1 kernel 2015-05-05 Ubuntu USN-2598-1 kernel 2015-05-05 Ubuntu USN-2600-1 kernel 2015-05-05 Ubuntu USN-2601-1 kernel 2015-05-05 Debian-LTS DLA-246-1 linux-2.6 2015-06-17 Fedora FEDORA-2015-8518 kernel 2015-05-26 Ubuntu USN-2589-1 linux-lts-utopic 2015-04-30 Ubuntu USN-2583-1 kernel 2015-04-30 Ubuntu USN-2590-1 kernel 2015-04-30 Ubuntu USN-2584-1 EC2 kernel 2015-04-30 Debian DSA-3237-1 kernel 2015-04-26 Ubuntu USN-2632-1 linux-ti-omap4 2015-06-10 Ubuntu USN-2612-1 linux-ti-omap4 2015-05-20 SUSE SUSE-SU-2015:1071-1 kernel 2015-06-16 Ubuntu USN-2631-1 kernel 2015-06-10 Ubuntu USN-2620-1 kernel 2015-05-23 Ubuntu USN-2613-1 linux-lts-trusty 2015-05-20 Ubuntu USN-2611-1 kernel 2015-05-20 Ubuntu USN-2614-1 kernel 2015-05-20 Ubuntu USN-2619-1 linux-lts-trusty 2015-05-23 Ubuntu USN-2615-1 linux-lts-utopic 2015-05-20 Debian-LTS DLA-246-2 linux-2.6 2015-06-17 Ubuntu USN-2616-1 kernel 2015-05-20

Comments (none posted)

libksba: denial of service

Package(s):	libksba	CVE #(s):
Created:	April 24, 2015	Updated:	November 30, 2015
Description:	From the Mageia bug report: Now returns an error instead of terminating the process for certain bad BER encodings.
Alerts:	openSUSE openSUSE-SU-2015:2155-1 libksba 2015-11-30 openSUSE openSUSE-SU-2015:2057-1 libksba 2015-11-20 Mandriva MDVSA-2015:214 libksba 2015-04-29 Mageia MGASA-2015-0166 libksba 2015-04-23

Comments (none posted)

libreoffice: code execution

Package(s):	libreoffice openoffice	CVE #(s):	CVE-2015-1774
Created:	April 27, 2015	Updated:	August 4, 2015
Description:	From the Debian advisory: It was discovered that missing input sanitising in Libreoffice's filter for HWP documents may result in the execution of arbitrary code if a malformed document is opened.
Alerts:	Gentoo 201603-05 libreoffice 2016-03-09 Scientific Linux SLSA-2015:1458-1 libreoffice 2015-08-03 Oracle ELSA-2015-1458 libreoffice 2015-07-29 Red Hat RHSA-2015:1458-01 libreoffice 2015-07-22 openSUSE openSUSE-SU-2015:0859-1 libreoffice 2015-05-12 Fedora FEDORA-2015-7213 libreoffice 2015-05-10 Mageia MGASA-2015-0174 libreoffice 2015-04-30 Fedora FEDORA-2015-7022 libreoffice 2015-04-29 Ubuntu USN-2578-1 libreoffice 2015-04-27 Debian DSA-3236-1 libreoffice 2015-04-25

Comments (none posted)

network-manager: information disclosure

Package(s):	network-manager	CVE #(s):	CVE-2015-1322
Created:	April 28, 2015	Updated:	April 29, 2015
Description:	From the Ubuntu advisory: Tavis Ormandy discovered that NetworkManager incorrectly filtered paths when requested to read modem device contexts. A local attacker could possibly use this issue to bypass privileges and manipulate modem device configuration or read arbitrary files.
Alerts:	Ubuntu USN-2581-1 network-manager 2015-04-28

Comments (none posted)

ntp: denial of service

Package(s):	ntp	CVE #(s):	CVE-2015-3405
Created:	April 28, 2015	Updated:	April 29, 2015
Description:	From the Red Hat bugzilla: A flaw was found in the way the ntp-keygen utility generated MD5 symmetric keys on big-endian systems. This could possibly allow an attacker to guess generated MD5 keys that could then be used to spoof an NTP client or server. If the lowest byte of the temp variable is outside of the printable characters range (between 0x20 and 0x7f), the ntp-keygen utility enters an infinite loop. However, if the temp variable is within the aforementioned range, the generated MD5 key will consist of 20 identical characters, meaning only 93 possible keys can be generated.
Alerts:	Scientific Linux SLSA-2015:2231-4 ntp 2015-12-21 Oracle ELSA-2015-2231 ntp 2015-11-23 Red Hat RHSA-2015:2231-04 ntp 2015-11-19 Debian DSA-3388-1 ntp 2015-11-01 Scientific Linux SLSA-2015:1459-1 ntp 2015-08-03 Oracle ELSA-2015-1459 ntp 2015-07-29 Red Hat RHSA-2015:1459-01 ntp 2015-07-22 SUSE SUSE-SU-2015:1173-1 ntp 2015-07-02 Fedora FEDORA-2015-5830 ntp 2015-04-28

Comments (none posted)

oxide-qt: code execution

Package(s):	oxide-qt	CVE #(s):	CVE-2015-1321
Created:	April 28, 2015	Updated:	April 29, 2015
Description:	From the Ubuntu advisory: A use-after-free was discovered in the file picker implementation. If a user were tricked in to opening a specially crafted website, an attacker could potentially exploit this to cause a denial of service via application crash or execute arbitrary code with the privileges of the user invoking the program.
Alerts:	Ubuntu USN-2570-1 oxide-qt 2015-04-27

Comments (none posted)

powerdns: denial of service

Package(s):	powerdns	CVE #(s):	CVE-2015-1868
Created:	April 24, 2015	Updated:	July 22, 2015
Description:	From the Arch Linux advisory: A bug was discovered in our label decompression code, making it possible for names to refer to themselves, thus causing a loop during decompression. This loop is capped at a 1000 iterations by a failsafe, making the issue harmless on most platforms. However, on specific platforms, the recursion involved in these 1000 steps causes memory corruption leading to a quick crash, presumably because the default stack is too small.
Alerts:	Mageia MGASA-2015-0301 pdns 2015-08-03 openSUSE openSUSE-SU-2015:1278-1 pdns pdns-recursor 2015-07-22 Debian DSA-3307-1 pdns-recursor 2015-07-10 Debian DSA-3306-1 pdns 2015-07-10 Mageia MGASA-2015-0189 pdns, pdns-recursor 2015-05-05 Fedora FEDORA-2015-7079 pdns-recursor 2015-04-30 Fedora FEDORA-2015-7031 pdns-recursor 2015-04-30 Fedora FEDORA-2015-7057 pdns 2015-04-30 Fedora FEDORA-2015-7047 pdns 2015-04-30 Arch Linux ASA-201504-27 powerdns-recursor 2015-04-24 Arch Linux ASA-201504-26 powerdns 2015-04-24

Comments (none posted)

python-Pillow: denial of service

Package(s):	python-Pillow	CVE #(s):	CVE-2014-3598
Created:	April 29, 2015	Updated:	April 29, 2015
Description:	From the openSUSE advisory: Remote attackers could cause a denial of service using specially crafted image files via IcnsImagePlugin
Alerts:	openSUSE openSUSE-SU-2015:0798-1 python-Pillow 2015-04-29

Comments (none posted)

sqlite: three vulnerabilities

Package(s):	sqlite	CVE #(s):	CVE-2015-3414 CVE-2015-3415 CVE-2015-3416
Created:	April 23, 2015	Updated:	August 18, 2015
Description:	From the Fedora advisory: [ 1 ] Bug #1212353 - sqlite: use of uninitialized memory when parsing collation sequences in src/where.c https://bugzilla.redhat.com/show_bug.cgi?id=1212353 [ 2 ] Bug #1212356 - sqlite: invalid free() in src/vdbe.c https://bugzilla.redhat.com/show_bug.cgi?id=1212356 [ 3 ] Bug #1212357 - sqlite: stack buffer overflow in src/printf.c https://bugzilla.redhat.com/show_bug.cgi?id=1212357
Alerts:	Scientific Linux SLSA-2015:1634-1 sqlite 2015-08-17 Oracle ELSA-2015-1634 sqlite 2015-08-17 Oracle ELSA-2015-1635 sqlite 2015-08-17 CentOS CESA-2015:1635 sqlite 2015-08-17 CentOS CESA-2015:1634 sqlite 2015-08-17 Scientific Linux SLSA-2015:1635-1 sqlite 2015-08-17 Red Hat RHSA-2015:1635-01 sqlite 2015-08-17 Red Hat RHSA-2015:1634-01 sqlite 2015-08-17 Ubuntu USN-2698-1 sqlite3 2015-07-30 Slackware SSA:2015-198-02 php 2015-07-17 Gentoo 201507-05 sqlite 2015-07-07 Debian DSA-3252-1 sqlite3 2015-05-06 Mandriva MDVSA-2015:217 sqlite3 2015-04-30 Fedora FEDORA-2015-6349 spatialite-tools 2015-04-26 Fedora FEDORA-2015-6349 sqlite 2015-04-26 Fedora FEDORA-2015-6324 spatialite-tools 2015-04-22 Fedora FEDORA-2015-6324 sqlite 2015-04-22 Debian DSA-3252-2 sqlite3 2015-06-14 Mageia MGASA-2015-0234 firefox, thunderbird, sqlite3 2015-05-18

Comments (none posted)

t1utils: multiple vulnerabilities

Package(s):	t1utils	CVE #(s):	CVE-2015-3905
Created:	April 24, 2015	Updated:	July 10, 2015
Description:	According to the Mageia bug report, t1utils prior to version 1.39 was subject to three separate bugs that could result in a denial of service: a buffer overrun, an infinite loop, and a stack overflow in t1disasm.
Alerts:	Gentoo 201507-10 t1utils 2015-07-10 Debian-LTS DLA-256-1 t1utils 2015-06-29 Mandriva MDVSA-2015:215 t1utils 2015-04-29 Mageia MGASA-2015-0167 t1utils 2015-04-23 Ubuntu USN-2627-1 t1utils 2015-06-03 Fedora FEDORA-2015-7581 t1utils 2015-05-17 Fedora FEDORA-2015-7654 t1utils 2015-05-17

Comments (none posted)

usb-creator: privilege escalation

Package(s):	usb-creator	CVE #(s):
Created:	April 24, 2015	Updated:	April 29, 2015
Description:	From the Ubuntu advisory: Tavis Ormandy discovered that usb-creator was missing an authentication check. A local attacker could use this issue to gain elevated privileges.
Alerts:	Ubuntu USN-2576-2 usb-creator 2015-04-23 Ubuntu USN-2576-1 usb-creator 2015-04-23

Comments (none posted)

wordpress: multiple vulnerabilities

Package(s):	wordpress	CVE #(s):	CVE-2015-3438 CVE-2015-3439 CVE-2015-3440
Created:	April 27, 2015	Updated:	May 21, 2015
Description:	From the WordPress announcement: WordPress versions 4.1.1 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported by Cedric Van Bockhaven and fixed by Gary Pendergast, Mike Adams, and Andrew Nacin of the WordPress security team. We also fixed three other security issues: In WordPress 4.1 and higher, files with invalid or unsafe names could be uploaded. Discovered by Michael Kapfer and Sebastian Kraemer of HSASec. In WordPress 3.9 and higher, a very limited cross-site scripting vulnerability could be used as part of a social engineering attack. Discovered by Jakub Zoczek. Some plugins were vulnerable to an SQL injection vulnerability. Discovered by Ben Bidner of the WordPress security team.
Alerts:	Debian-LTS DLA-633-1 wordpress 2016-09-22 Mageia MGASA-2015-0202 wordpress 2015-05-09 Debian DSA-3250-1 wordpress 2015-05-04 Mageia MGASA-2015-0170 wordpress 2015-04-25 Fedora FEDORA-2015-6790 wordpress 2015-05-20 Debian-LTS DLA-236-1 wordpress 2015-06-01 Fedora FEDORA-2015-6808 wordpress 2015-05-20

Comments (none posted)

wpa_supplicant: code execution

Package(s):	wpa_supplicant	CVE #(s):	CVE-2015-1863
Created:	April 24, 2015	Updated:	May 13, 2015
Description:	From the Ubuntu advisory: It was discovered that wpa_supplicant incorrectly handled SSID information when creating or updating P2P peer entries. A remote attacker could use this issue to cause wpa_supplicant to crash, resulting in a denial of service, expose memory contents, or possibly execute arbitrary code.
Alerts:	Gentoo 201606-17 hostapd 2016-06-27 Red Hat RHSA-2015:1090-01 wpa_supplicant 2015-06-11 Fedora FEDORA-2015-6952 wpa_supplicant 2015-05-12 Slackware SSA:2015-132-03 wpa_supplicant 2015-05-12 CentOS CESA-2015:1090 wpa_supplicant 2015-06-15 Scientific Linux SLSA-2015:1090-1 wpa_supplicant 2015-06-11 Oracle ELSA-2015-1090 wpa_supplicant 2015-06-11 openSUSE openSUSE-SU-2015:0813-1 wpa_supplicant 2015-05-01 Fedora FEDORA-2015-6860 wpa_supplicant 2015-04-27 Debian DSA-3233-1 wpa 2015-04-24 Arch Linux ASA-201504-29 wpa_supplicant 2015-04-24 Ubuntu USN-2577-1 wpa_supplicant 2015-04-23

Comments (none posted)

yourls: cross-site scripting

Package(s):	yourls	CVE #(s):	CVE-2014-8488
Created:	April 29, 2015	Updated:	April 29, 2015
Description:	From the CVE entry: Cross-site scripting (XSS) vulnerability in the administrator panel in Yourls 1.7 allows remote attackers to inject arbitrary web script or HTML via a URL that is processed by the Shorten functionality.
Alerts:	Fedora FEDORA-2015-5972 yourls 2015-04-29 Fedora FEDORA-2015-6002 yourls 2015-04-29

Comments (none posted)

Kernel release status

The current development kernel is 4.1-rc1, released on April 26. Linus said: "No earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of 'big new feature' may differ from mine, of course. There's a lot of work all over, and some of it might just make a big difference to your use cases."

Stable updates: 4.0.1, 3.19.6, 3.14.40, and 3.10.76 were all released on April 29.

Comments (none posted)

Quotes of the week

— Andy Lutomirski (thanks to Cesar Eduardo Barros)

— Linus Torvalds

Comments (none posted)

Garrett: Reducing power consumption on Haswell and Broadwell systems

Matthew Garrett looked into why Linux systems consume too much power on recent Intel chipsets and wrote up his results — a reduction of idle power use on his laptop from 8.5W to 5W. "This trend is likely to continue. As systems become more integrated we're going to have to pay more attention to the interdependencies in order to obtain the best possible power consumption, and that means that distribution vendors are going to have to spend some time figuring out what these dependencies are and what the appropriate default policy is for their users."

Comments (45 posted)

The 4.1 merge window closes

By the time Linus released 4.1-rc1 and closed the merge window for this development cycle, some 10,659 non-merge changesets had been pulled into the mainline repository. That makes 4.1 a reasonably busy development cycle, but far from the busiest; 3.19 had 11,400 changes during the merge window, and 3.15, the record holder, had just over 12,000. Even if 4.1 is not a record breaker, though, anybody who worried that 4.0 signaled a general slowdown in kernel development can rest easier now.

Only about 900 of those changesets were pulled since last week's summary, but there were some interesting changes buried in that last batch. Some of the more significant, user-visible changes include:

• The XFS filesystem has gained RENAME_WHITEOUT support, meaning that it should now work with the overlayfs union filesystem. Also new in XFS is support for the FALLOC_FL_INSERT_RANGE option to fallocate(), allowing applications to insert a hole into a file.

• The Btrfs filesystem has seen some important fixes, though they may not be hugely relevant for many users: they apply to filesystems 20TB and larger or to individual files that are 3TB or larger.

• The virtio subsystem has a new virtio-input driver; its job is to collect and forward input-device events to a virtual device.

• The arm64 architecture has gained support for the Advanced Configuration and Power Interface, otherwise known as ACPI. Supporting ACPI for ARM has been controversial in the past; many developers would rather see the device tree mechanism used universally for hardware discovery on that architecture. The addition of ACPI happened quietly in the end, though, and it seems likely that there will be servers using ACPI shipping in the near future. That said, there is still some work to do; the merge commit notes that "we don't support any peripherals yet, so it's fairly limited in scope." See Documentation/arm64/arm-acpi.txt for a lot of information about ACPI on ARM.

• The MD (RAID) subsystem can now manage RAID 1 arrays in a distributed fashion across a cluster. This code is currently marked as being experimental, but it is evidently nearing a production-ready state.

• New hardware support includes:
  • DMA: Ingenic JZ4780 DMA controllers, Renesas USB-DMA controllers, Applied Micro X-Gene SoC DMA engines, and Freescale RAID engines.

  • Miscellaneous: ChromeOS embedded controllers, ChromeOS "lightbar" devices, and Dell keyboard backlights.

Changes visible to kernel developers include:

• The "exception table" lists locations in the kernel that might generate faulting address references; in essence, the table contains a list of every invocation of copy_*_user() and related functions. When a fault happens in kernel mode, this table is consulted to see whether the fault was expected or not. This mechanism allows the kernel to safely access user-space data without having to explicitly check each pointer before dereferencing it.

  Each loadable module has an exception table of its own to mark such invocations. As of 4.1, the module loader will actively check to ensure that every exception-table entry points to a location within the module's executable text. Any entry not pointing to a known text section must be erroneous, but evidently they come up, especially in situations where a new executable section is being added to the kernel. Developers will want to watch out for this new type of failure, especially when working on the less-mainstream architectures.

One thing that did not get merged this time around was the kdbus interprocess communication system. Linus did not comment on his decision to leave it out, but it seems clear that this code was too controversial to be pulled straight into the mainline. Now both the supporters of kdbus and those who are concerned about aspects of its design have another development cycle to discuss the issues, and, hopefully, come to some sort of conclusion that allows kdbus to proceed.

Meanwhile, the 4.1 kernel is now in the stabilization phase of the development cycle. If things follow the recent pattern, the final 4.1 kernel release will happen on June 14.

Comments (1 posted)

Pagemap: security fixes vs. ABI compatibility

The kernel development community maintains a strong commitment to ABI compatibility; as a general rule, changes that will break existing applications are not allowed. But the community is also committed to fixing known security problems. There are times when a security issue cannot be fixed without changing the way a user-visible interface works, and that can lead to problems. One such situation has come up as the result of a change merged for the 4.0 kernel.

Back in 2008, the 2.6.25 kernel included a patch adding a new virtual file (called pagemap) to each process's /proc directory. That file contains an array of 64-bit values describing each page in the process's virtual address space. If the page is currently resident, the physical page-frame number will be given; otherwise, information on how to find the page in swap is provided. The original purpose for the pagemap file was to enable investigations into which pages were resident and which were shared with other processes. Documentation/vm/pagemap.txt has information on what can be found in this file.

At the time this patch was merged, there appeared to be no harm in exposing the physical page-frame information. Since then, though, sentiments have turned against disclosing internal kernel information that is not strictly needed by user space. That, alone, might have eventually inspired somebody to remove the page-frame number from the pagemap file but, as it happens, something else came along first.

That something is the "rowhammer vulnerability," wherein the contents of a memory area can be changed by repeatedly hammering on a nearby memory area. If an attacker wanted to use this technique to compromise a system, the first order of business would be to obtain access to a page of memory physically adjacent to the memory that is targeted to be changed. The contents of the pagemap file, by providing the physical location of every page mapped in the system, would obviously be most helpful in such a situation. There will probably be other ways for an attacker to determine how pages are laid out in physical memory, but pagemap is almost certainly the easiest way.

To make life harder for attackers attempting to exploit the rowhammer vulnerability, a simple patch was merged for the 4.0-rc5 release in March. The patch turned the pagemap file into a privileged interface; attempts to open it will now fail unless the process in question has the CAP_SYS_ADMIN capability. The 4.0 release came out with that restriction in place, and everybody who was paying attention slept a little easier.

But that rest appears to have come at the cost of some sleepless nights elsewhere. It turns out that the UndoDB debugger uses the pagemap file to track changes to memory. When changes need to be tracked, the debugger will fork() the process, putting all of its writable memory into copy-on-write mode. After running the operation of interest (a system call, normally), the debugger can scan the pagemap file to see which pages have changed page-frame numbers; those are the pages that were written to, and, thus, copied. Without access to pagemap, UndoDB cannot get this information and, as a result, it no longer works.

In some situations of this type, one might just argue that the tool in question should be run as root. But that is not generally a desirable way to run an interactive debugging tool. So some other sort of solution must be found, or UndoDB will remain broken. There are cases where "remains broken" may be the final outcome; as Linus said in response to the report, "the one exception to the regression rule is 'security fixes'". But, fortunately, there appear to be some better options available this time around.

One possibility would be to restore access to the pagemap file but to somehow scramble the page-frame numbers before reporting them to user space. That would work for UndoDB, since it doesn't care about the actual page-frame numbers; it is only looking for changes. Linus was not convinced that this was the right way to go, though:

Andy Lutomirski also pointed out that even scrambled page-frame numbers might be enough for an attacker to obtain some memory-adjacency information. So that approach does not appear to be viable.

The alternative is to simply report the page-frame numbers as zero in the absence of CAP_SYS_ADMIN. That would make the rest of the information in pagemap available while not exposing the page-frame information. The bad news is that always-zero page-frame numbers are not helpful for UndoDB. The good news, though, is that there is something else in pagemap that is just as useful.

That "something else" is the "soft-dirty" mechanism added to the 3.11 kernel in support of the checkpoint-restore in user space (CRIU) effort. Along with the page-frame number, each pagemap entry contains a soft-dirty bit that is meant to track pages that have been written to. All of the soft-dirty bits for a process can be reset to zero by writing to the clear_refs file in that process's /proc directory. Thereafter, the soft-dirty bit will be set whenever that process writes to a given page. CRIU uses this mechanism to find pages that have been changed during the checkpoint process, but it also will work for the UndoDB case. (See Documentation/vm/soft-dirty.txt for details on the soft-dirty mechanism).

So the probable outcome in this case is that pagemap will, once again, become globally readable. But it will contain no useful page-frame numbers unless the reading process had CAP_SYS_ADMIN when it opened the file. That will make UndoDB users happy again while preserving the security objectives of the original patch. So this story has a happy ending — unless, of course, another user who truly needs the page-frame number information steps forward.

Comments (6 posted)

Tracking actual memory utilization

One might be tempted to think that an operating-system kernel should be able to answer a simple question: how much memory is a given process actually using? But, despite all the effort that has gone into providing visibility for this type of data, simple answers can be hard to come by. So the effort to provide better information continues, as can be seen by a recent patch set from Vladimir Davydov adding another way to calculate memory utilization.

A process's resident set size (RSS) is relatively easily calculated; that is the number of pages of physical memory currently owned by that process. Interested parties can get this information now from /proc or the ps command. In theory, the kernel is handling page reclaim in such a way that each process is actually using every page in its resident set, but, in the real world, things don't always work out that way.

It can be worth knowing if there is a significant difference between a process's RSS and the amount of memory actually in use; this information can be helpful when partitioning the system between containers or setting control-group limits. As it happens, the kernel contains a mechanism designed to allow an observer to determine how much of a process's resident set has actually been referenced. That information is found in a virtual file called smaps in the process's /proc directory. For example, the following fragment comes from the smaps file corresponding the the X.org server on your editor's desktop:

    016bc000-04af4000 rw-p 00000000 00:00 0                      [heap]
    Size:              53472 kB
    Rss:               51936 kB
    Pss:               51936 kB
    Shared_Clean:          0 kB
    Shared_Dirty:          0 kB
    Private_Clean:         0 kB
    Private_Dirty:     51936 kB
    Referenced:        45384 kB
    Anonymous:         51936 kB
    AnonHugePages:     38912 kB
    Swap:                  0 kB
    KernelPageSize:        4 kB
    MMUPageSize:           4 kB
    Locked:                0 kB
    VmFlags: rd wr mr mw me ac 

This entry describes an anonymous memory area that occupies 53,472KB of memory; 51,936KB of that area is currently resident (the Rss field), and 45,384KB have been referenced (the line in bold) since tracking was last reset. Since nothing is monitoring memory use on this system, that number has never been reset and thus counts every page referenced since the X.org server started.

If one wants to track usage over a specific period, it is necessary to reset the "referenced" count at the beginning, let the process run for a bit, then look in smaps to see how much memory was actually touched. That reset is done by writing a value of 1 to the clear_refs file in the same /proc directory.

At a first look, this mechanism seems like it should be able to answer the question of how much memory a process is actually using. But it turned out to not meet Vladimir's needs for a couple of reasons. One of those is that, while the smaps entry tracks references to memory mapped into the process's address space, it does not track page-cache memory used when files are accessed with system calls like read() or write(). That memory, too, is used by the process, so there would be value in knowing how much of it there is. Perhaps more importantly, the "referenced" state of each page is used by the memory-management subsystem itself to make decisions on which pages to evict. Resetting every page to the "not referenced" state will thus perturb page reclaim, and probably not for the better. If these measurements are to be made often, it would be good to have a less invasive way to make them.

Vladimir's patch adds a new file called /proc/kpageidle; since it's in the top-level /proc directory, it's a single file that describes an aspect of the the global state of the system. The file can be read like a long array of 64-bit integer values; each value corresponds to one physical page in the system, indexed by page-frame number. If a program wants to know whether physical page N has been referenced, it can seek to the appropriate location in /proc/kpageidle and read the value there; if the lowest bit is set, the page is idle. (Note that this file may change to a bitmap format in a future version of the patch set).

Once again, one needs to be able to reset that state to make observations over a given time period; in this case, setting a page to the "idle" state is done by writing 1 to the appropriate location in /proc/kpageidle. That action will make the page inaccessible (much like the normal kernel usage tracking does) so that a fault will result whenever a process tries to read or write that page. At that point, the "idle" state can be reset and the page made accessible again. The idle state will also be reset if the page is accessed via the file-related system calls, so it will track the state of pages in the page cache as well.

To track the idle state, the patch set adds a new "idle" page flag that is set whenever a page is marked idle. That flag is then passed back to user space whenever a given page's entry in /proc/kpageidle is read. As it turns out, there is a need for a second page flag as well, though. As mentioned above, making a page inaccessible is a technique already used within the memory-management subsystem; when a write to /proc/kpageidle causes that to happen, it makes the page appear to have never been accessed. To avoid that, Vladimir adds a second flag called "young"; whenever a write to /proc/kpageidle makes a page inaccessible, the "young" bit will be set as well. When the memory-management code asks whether a page has been referenced, the "young" bit is taken into account. In the end, that means that using /proc/kpageidle will not change how page reclaim is done.

There is one little problem with this approach: page flags are in short supply on 32-bit systems. To get around this problem, the code uses the "struct page extension" mechanism in the 32-bit case. This mechanism was originally created to support memory control groups (memcgs), which need to store more information about each page than can fit in the page structure. Using extensions can use quite a bit of memory in its own right, but there's little alternative on systems where shoehorning even one more bit into struct page is not an option.

Readers who have gotten this far may be wondering about one final piece of the puzzle: knowing which physical pages in the system are in use does not say much about what any specific processes are using. There are two ways of connecting the two pieces, one of which exists now and one which is part of Vladimir's patch. In current systems, the pagemap file in any process's /proc directory can be used to see which physical pages are mapped into that process's address space. That information is only available to privileged processes as of the 4.0 release, but /proc/kpageidle is a privileged interface too.

If the task at hand is partitioning a system's resources, though, then memcgs are likely already in use to set limits on groups of processes. In that case, it is more interesting to know how much memory each memcg is using than to track this information on a per-process basis. To that end, the patch set adds yet another file (/proc/kpagecgroup) which, when read, yields the control group that owns each page. By using that file together with /proc/kpageidle, a monitoring process can determine how many pages each memcg is using — and how many it owns but is not making use of.

The end result is an interface that can be used to determine how well a control group's memory limits fit its actual needs. As service providers of all types seek to run more clients on each physical system, they will likely be pleased to have this extra information available. That, of course, depends on this patch set being merged into the mainline. Given the lack of significant opposition, that seems likely to happen sooner or later — though, with memory-management patches, it's always hard to say just when that might happen.

Comments (4 posted)

Debian plans for Python 3

Moving a distribution to Python 3 is a big job, but there is a clear deadline for Python 2: it will be unsupported by upstream in 2020 (or at least that is the plan). That may seem far away, but it is only roughly two Debian release cycles from now. By the time Debian 10.0 ("Buster") is released, all of Debian's tools, and most of its packages, should be using Python 3 if all goes according to plan. Paul Tagliamonte and a "shadowy Debian Python cabal" met at PyCon 2015 to discuss this issue with an eye toward creating a plan of attack.

The rudiments of that plan were outlined by Tagliamonte after the conference. The first step, he said, is to look at things that are completely under Debian's control, which is its infrastructure. He asked those who are working on infrastructure projects to send him a census of the tools, their dependencies, and their Python versions, so that he could start building a tree of dependencies.

He also suggested filing bugs for packages that support Python 3 upstream, but are not built that way for Debian, as well as for packages that do not have Python 3 support at all. Beyond that, he suggested porting any projects that only support Python 2 to support both with a hybrid 2/3 code base. Finally, he will be forming a "Python 3 porting team" to help move the code in Debian's infrastructure to Python 2/3.

Those are ambitious plans, of course, and, as evidenced by the first census response, there are still wrinkles to be worked out. Enrico Zini listed half a dozen services that he maintains (e.g. contributors.debian.org, debtags.debian.net) along with their dependencies, which were mostly things like the Django web framework, database access libraries, and other web-focused Python packages. He noted that he is in favor of switching to Python 3, in principle, but there are some barriers to doing so:

Zini is willing to work with the porting team, but he wants to be sure that the team will continue its effort past the initial port. If incompatible changes come in three or four years as part of Python 3.7, say, he wants someone to be responsible for whatever forward porting is needed. It is clear that Zini feels that he has been burned by Python's changes in the past and is happy to see the stability offered by the feature-frozen 2.7 branch.

Tagliamonte acknowledged Zini's concerns with regard to the porting team's help now and in the future. He suggested that the team could focus on making both the dependencies and Zini's services run on both 2 and 3:

But Zini had some concerns about accepting patches that use the six compatibility library or, at least, that use it indiscriminately. He wants maintainable code moving forward:

In addition, adding Python 3 support adds to the testing burden, Zini said. There were several suggestions of tools (e.g. tox, nose2) that would help, but the fact remains that someone has to run the tests and fix any fallout. He would like to see that be handled by the porting team (or someone else) at least until 2019 or so, when Python 3 is ascendant and Python 2 largely gone.

Beyond the porting question, Zini also noted that there might be some problems running the services in production atop Python 3. Debian infrastructure runs on Debian stable, so any packages required to run the services would need to be available for stable as well. As Scott Kitterman pointed out, the fact that there will be two releases of Debian in the interim makes the production transition easier. There is a goal to have all of the dependencies available in Debian 9.0 ("Stretch"), so that the final switch for 10.0 will go smoothly.

That discussion should provide a bit of the flavor of the work ahead for the Python 3 porting team. It is clear that the dependencies are the key piece of the puzzle at this point, and that is where the focus is. Tagliamonte has created a new py3porters-devel mailing list to discuss plans and coordinate action going forward. It is a big task, but one that Debian appears to be getting a good head start on.

Comments (4 posted)

Ubuntu 15.04 (Vivid Vervet) released

The Ubuntu 15.04 release is out. "Ubuntu Server 15.04 includes the Kilo release of OpenStack, alongside deployment and management tools that save devops teams time when deploying distributed applications - whether on private clouds, public clouds, x86 or ARM servers, or on developer laptops. Several key server technologies, from MAAS to Ceph, have been updated to new upstream versions with a variety of new features. This release also includes the first release of snappy Ubuntu Core, a new distribution model based on transactional updates." LWN looked at Snappy in January.

Full Story (comments: none)

Debian 8 "Jessie" released

Debian 8, codenamed "Jessie", has been released. It comes with a wide array of upgraded packages including GNOME 3.14, KDE Plasma Workspaces and KDE Applications 4.11.13, Python 2.7.9 and 3.4.2, Perl 5.20.2, PHP 5.6.7, PostgreSQL 9.4.1, MariaDB 10.0.16 and MySQL 5.5.42, Linux 3.16.7-ctk9, and lots more. "With this broad selection of packages and its traditional wide architecture support, Debian once again stays true to its goal of being the universal operating system. It is suitable for many different use cases: from desktop systems to netbooks; from development servers to cluster systems; and for database, web, or storage servers. At the same time, additional quality assurance efforts like automatic installation and upgrade tests for all packages in Debian's archive ensure that "Jessie" fulfills the high expectations that users have of a stable Debian release."

Full Story (comments: 150)

First Jessie based Debian Edu beta release

The Debian Edu / Skolelinux project has announced the first beta release of Debian Edu "Jessie" 8.0+edu0~b1, which is composed entirely of packages from the recently released Debian 8.0. "We expect to make a final release of Debian Edu "Jessie" in the coming weeks, timed with the first point release of Debian Jessie. Upgrades from this beta release of Debian Edu Jessie to the final release will be possible and encouraged!"

Full Story (comments: none)

Join the LTS project to help shape Wheezy and Jessie LTS

The Debian Long Term Support (LTS) project has been active for almost a year, maintaining "Squeeze" LTS (Debian 6). The LTS team has announced that they are planning on supporting both Debian 7 "Wheezy" and Debian 8 "Jessie" after the official end-of-life. "However, some restrictions in coverage had to be made for Squeeze LTS. For example, only x86 PCs (amd64 and i386) are supported, and a number of popular packages are unsupported. For example, you cannot run a Xen dom0 or a KVM host with Squeeze, and there isn't support for graphical browsers. The current team resources are only enough to keep up with the observed workload, and would not be sufficient to extend this further. Thus, if you want Wheezy LTS to have a better coverage for such use cases and for less popular packages, please consider helping the Debian LTS team, either with developer time or with funding."

Full Story (comments: none)

The Jessie release got a bit Stretch'ed

The Debian release team has a few post-release words to share. Topics include plans for the first "Jessie" point release, and of course, Stretch. This is the time when there could be major toolchain updates and other large transitions or changes to unstable and testing (now Stretch).

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 607 (April 27)
• 5 things in Fedora this week (April 24)
• Ubuntu Weekly Newsletter, Issue 414 (April 26)

Comments (none posted)

Qubes 3.0-rc1 ISO and roadmap for 2015

Joanna Rutkowska has announced the release of Qubes 3.0-rc1 and presents a roadmap for future development. "The major new feature coming in the next release (Qubes 3.1) is the management and pre-configuration infrastructure. This is gonna be a basis for both remote management (e.g. for corporate Qubes editions) and also for preparing customized Qubes editions/configurations for specific users/use cases. More on this important topic in an upcoming article."

Comments (none posted)

Recovering data with PhotoRec and TestDisk 7

Data recovery is a topic that few people enjoy talking about, but it is a fact of life. Storage hardware fails, devices get damaged, and accidents happen. For many years, Christophe Grenier's TestDisk and PhotoRec utilities have been among the most reliable tools available for the task. Version 7.0 of both programs (which are developed and released together) were released on April 18 after a lengthy development and testing cycle, bringing support for more filesystem options and for recovering new file types.

Both TestDisk and PhotoRec operate by performing low-level scans of a hard disk's sectors, but for different purposes. TestDisk searches for lost partition and boot-sector information in order to help users recover a corrupted or damaged partition, partition table, or boot sector. PhotoRec searches partitions or entire disks for file headers that match the patterns from a user-selected list of file types.

As the name suggests, PhotoRec was initially designed to recover lost or deleted image files from digital camera flash storage. Now, however, it can recognize more than 260 file types—although the emphasis remains on media formats, rather than (say) executables, and it is skewed toward actively developed applications. TestDisk can read and restore a wide variety of partition table formats and filesystems, including newer formats like Btrfs, and it supports mdadm RAID arrays, logical volume manager (LVM) drives, and all major flavors of full-disk encryption.

Version 7.0 was a long-in-development release. The previous stable release, 6.14, was made in July 2013. Although both programs are packaged by many desktop Linux distributions, the tools' usefulness in forensic and data-recovery tasks also makes them a popular choice for inclusion with smaller "rescue" distributions designed to boot from removable media. Downloads are available for 32-bit and 64-bit Intel systems, as is source code.

Due to the lengthy development cycle for 7.0, a number of these rescue distributions have been shipping pre-release builds of 7.0 for some time. For the most part, these pre-release builds support the same feature set as the 7.0 final release. A lot of the most recent work leading up to the release was devoted to fixing bugs—security bugs in particular.

The project highlighted three separate security reviews performed in the lead up to the 7.0 release. One was a static-analysis scan conducted by Coverity. The second was a fuzz test performed with the american fuzzy lop (afl) fuzzer. The third was a review done by Security Assessment that turned up an exploitable buffer overflow.

Apart from the security issues fixed as a result of these reviews, the changes to TestDisk 7.0 include improved support for the exFAT filesystem (which is commonly used on flash storage media, particularly on cards over 32GB in size) and improvements to ext4 support. In particular, ext4 support now includes correct handling of 64-bit block numbers and 64KB block sizes and reading the ext4 journal. ExFAT support now includes proper handling of non-ASCII file and directory names.

PhotoRec gained support for recognizing 14 new file types, including several from free-software applications. These include Krita's native format as well as the OpenRaster format produced by Krita, MyPaint, and several other image-editing programs, the Magic Lantern Video raw-video format created by the Magic Lantern open-source camera firmware, openNURBS 3D geometry files, the Digital Imaging and Communications in Medicine (DICOM) format used in medical and scientific visualizations, and the Web Open Font Format (WOFF).

In addition, many of the file-detection functions in PhotoRec have seen improvements, such as the ability to detect the file size of a number of different formats (including MPEG, Flash video, GIF, and RealAudio). PhotoRec also includes a brute-force mode that can identify individual file fragments, potentially rescuing files that could not be located by file-header identification alone. This is a significantly processor-hungry operation, and the new release includes some significant brute-force-mode speedups in comparison to previous releases.

TestDisk has the potential to damage partitions if used incorrectly, although the same risk is found in any application that can be used to modify partition tables. Nevertheless, the application takes a number of steps to prevent accidental loss of information. It is interactive and menu-based, with most destructive operations requiring a confirmation to commit, and it can be run against saved disk images as well as against live disks. PhotoRec is not potentially destructive, since it requires the user to specify a separate directory for storing any recovered files.

There are a wide array of problems that can be solved between the two programs. The most common are, arguably, how to recover accidentally deleted files from a storage device and how to rescue files from a corrupted disk. I had an opportunity to do the latter recently, and found PhotoRec 7.0 to be remarkably fast at locating lost files.

Naturally, the speed of the storage device helps matters, but there are other factors that make using PhotoRec a good experience. Few alternatives present as much rescued data to the user in as short an amount of time. PhotoRec provides a running log of what it is locating while it scans through a disk, which gives you a rough idea of whether or not it is successfully reading the storage medium (and whether or not the files you are expecting to find are still there). It also defaults to running lightweight scans at the beginning, only progressing to the brute-force option if the user insists. The result is less time spent waiting for results and, potentially, less time wasted on an unrecoverable medium.

TestDisk is a bit more complicated to work with, as using it involves some detective work and some knowledge about the partitioning scheme used on the disk. For an older disk (which, naturally, is more likely to experience failures), the knowledge could be ancient history from the user's point of view. There are certainly valid alternatives to TestDisk for such disk-recovery tasks (such as gdisk), but most of them tend to expect more detailed knowledge of the appropriate recovery procedure. Where TestDisk has an advantage is in guiding users along the path to recovery one step at a time: beginning with quick and optimistic scans, then proceeding to more involved searches only where necessary.

The 7.0 release of both tools appears to be a solid upgrade. They have kept pace with newer filesystems (on Linux and other platforms) and with newer file-format developments as well. For a data-recovery utility, that is about the best that one can expect. Reviving lost storage is never a task one looks forward to, but at least it can be a reliable operation and comparatively painless.

Comments (1 posted)

Quotes of the week

— Ben Cotton

— Josh Triplett

Comments (3 posted)

KDE Ships Plasma 5.3

KDE has announced the release of Plasma 5.3. This release features improved power management, better Bluetooth capabilities, improved Plasma widgets, a tech preview of the Plasma Media Center, big steps towards Wayland support, and more.

Comments (12 posted)

WordPress 4.2 released

Version 4.2 of the WordPress blogging and content-management system has been released. New features include "Press This," a bookmark-able shortcut to create a new post from the current browser page, support for additional Unicode character sets (including Chinese, Japanese, and Korean scripts as well as Emoji), and improved accessibility with screen-reader support in the administration tools.

Comments (1 posted)

GNU Mailman 3.0 released

GNU Mailman 3.0 has been released. "Over seven years in development, Mailman 3 represents a major new version, redesigned as a suite of cooperating components which can be used to mix and match however you want. The core engine is now backed by a relational database and exposes its functionality to other components via an administrative REST+JSON API. Our new web user interface, Postorius is Django-based, as is our new archiver HyperKitty. The core requires Python 3.4 while Postorius and HyperKitty require Python 2.7. LWN looked at Mailman 3.0 in March, and at HyperKitty in April 2014.

Full Story (comments: 14)

Synfig Studio 1.0 released

Version 1.0 of the 2D animation suite Synfig Studio has been released. Among the notable changes are an updated GUI using GTK+ 3, reworked sound support, advanced image-deformation tools, and improvements to the "bones" system used to rig up animated characters for easier movement. Libre Graphics World has posted a look at the new release that also reviews the project's progress over the past few years.

Comments (none posted)

Development newsletters from the past week

• What's cooking in git.git (April 27)
• LLVM Weekly (April 27)
• OCaml Weekly News (April 28)
• OpenStack Community Weekly Newsletter (April 24)
• Perl Weekly (April 27)
• PostgreSQL Weekly News (April 26)
• Python Weekly (April 23)
• Ruby Weekly (April 23)
• This Week in Rust (April 27)
• Wikimedia Tech News (April 27)

Comments (none posted)

Rust Once, Run Everywhere

The Rust blog has posted a guide to using Rust's foreign function interface (FFI) with C code. Highlighted in particular are Rust's safe abstractions, which are said to impose no costs. "Most features in Rust tie into its core concept of ownership, and the FFI is no exception. When binding a C library in Rust you not only have the benefit of zero overhead, but you are also able to make it safer than C can! Bindings can leverage the ownership and borrowing principles in Rust to codify comments typically found in a C header about how its API should be used."

Comments (13 posted)

May 6th: Join an event against DRM

The Free Software Foundation's Defective By Design campaign announces some events happening for the International Day Against DRM, May 6. "There is currently at least one event scheduled in Guatemala, Italy, Portugal, the Netherlands and the USA. You can see the full list of currently scheduled events below. We'll keep updating the online version of this list, so if you don't see an event in your area, check back closer to May 6th."

Full Story (comments: none)

CFP Deadlines: April 30, 2015 to June 29, 2015

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
April 30	August 7 August 9	GNU Tools Cauldron 2015	Prague, Czech Republic
May 1	August 17 August 19	LinuxCon North America	Seattle, WA, USA
May 1	September 10 September 13	International Conference on Open Source Software Computing 2015	Amman, Jordan
May 1	August 19 August 21	KVM Forum 2015	Seattle, WA, USA
May 1	August 19 August 21	Linux Plumbers Conference	Seattle, WA, USA
May 2	August 12 August 15	Flock	Rochester, New York, USA
May 3	August 7 August 9	GUADEC	Gothenburg, Sweden
May 3	May 23 May 24	Debian/Ubuntu Community Conference Italia - 2015	Milan, Italy
May 8	July 31 August 4	PyCon Australia 2015	Brisbane, Australia
May 15	September 28 September 30	OpenMP Conference	Aachen, Germany
May 17	September 16 September 18	PostgresOpen 2015	Dallas, TX, USA
May 17	August 13 August 17	Chaos Communication Camp 2015	Mildenberg (Berlin), Germany
May 23	August 22 August 23	Free and Open Source Software Conference	Sankt Augustin, Germany
May 23	May 23 May 25	Wikimedia/MediaWiki European Hackathon	Lyon, France
May 31	October 2 October 4	PyCon India 2015	Bangalore, India
June 1	November 18 November 22	Build Stuff 2015	Vilnius, Lithuania
June 1	July 3 July 5	SteelCon	Sheffield, UK
June 5	August 20 August 21	Linux Security Summit 2015	Seattle, WA, USA
June 6	September 29 September 30	Open Source Backup Conference 2015	Cologne, Germany
June 11	June 25 June 28	Linux Vacation Eastern Europe 2015	Grodno, Belarus
June 15	August 15 August 22	DebConf15	Heidelberg, Germany
June 15	September 24	PostgreSQL Session 7	Paris, France
June 15	November 17 November 18	PGConf Silicon Valley	San Francisco, CA, USA
June 17	October 5 October 7	LinuxCon Europe	Dublin, Ireland
June 17	October 5 October 7	Embedded Linux Conference Europe	Dublin, Ireland
June 19	August 20	Tracing Summit	Seattle, WA, USA
June 28	August 28 September 3	ownCloud Contributor Conference	Berlin, Germany
June 28	November 11 November 13	LDAP Conference 2015	Edinburgh, UK

If the CFP deadline for your event does not appear here, please tell us about it.

Protocols Plugfest Europe 2015

Protocols Plugfest Europe 2015 will be held May 12-14 in Zaragoza, Spain. "Over 30 key specialist on interoperability (from top tech companies like Red Hat, Microsoft, Dell, Libelium, Kolab and open source projects like LibreOffice, Samba and OpenChange) will be at the event, giving cutting-edge sessions on Open source offerings, Microsoft interoperable products and technologies, and interoperable industry solutions." Registration is open.

Full Story (comments: none)

EuroPython 2015: Our next keynote: Ola & Ola (Django Girls)

Ola Sitarska and Ola Sendecka will be giving a keynote speech at EuroPython (July 20-26 in Bilbao, Spain). There will also be a Django Girls workshop at the conference.

Full Story (comments: none)

Events: April 30, 2015 to June 29, 2015

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
April 29 May 2	Libre Graphics Meeting 2015	Toronto, Canada
May 1 May 4	openSUSE Conference	The Hague, Netherlands
May 2 May 3	Kolab Summit 2015	The Hague, Netherlands
May 4 May 5	CoreOS Fest	San Francisco, CA, USA
May 6 May 8	German Perl Workshop 2015	Dresden, Germany
May 7 May 9	Linuxwochen Wien 2015	Wien, Austria
May 8 May 10	Open Source Developers' Conference Nordic	Oslo, Norway
May 12 May 13	PyCon Sweden 2015	Stockholm, Sweden
May 12 May 14	Protocols Plugfest Europe 2015	Zaragoza, Spain
May 13 May 15	GeeCON 2015	Cracow, Poland
May 14 May 15	SREcon15 Europe	Dublin, Ireland
May 16 May 17	11th Intl. Conf. on Open Source Systems	Florence, Italy
May 16 May 17	MiniDebConf Bucharest 2015	Bucharest, Romania
May 18 May 22	OpenStack Summit	Vancouver, BC, Canada
May 18 May 20	Croatian Linux User Conference	Zagreb, Croatia
May 19 May 21	SAMBA eXPerience 2015	Goettingen, Germany
May 20 May 22	SciPy Latin America 2015	Posadas, Misiones, Argentina
May 21 May 22	ScilabTEC 2015	Paris, France
May 23 May 25	Wikimedia/MediaWiki European Hackathon	Lyon, France
May 23 May 24	Debian/Ubuntu Community Conference Italia - 2015	Milan, Italy
May 30 May 31	Linuxwochen Linz 2015	Linz, Austria
June 1 June 2	Automotive Linux Summit	Tokyo, Japan
June 3 June 5	LinuxCon Japan	Tokyo, Japan
June 3 June 6	Latin American Akademy	Salvador, Brazil
June 5 June 7	PyCon APAC 2015	Taipei, Taiwan
June 8 June 10	Yet Another Perl Conference 2015	Salt Lake City, UT, USA
June 10 June 13	BSDCan	Ottawa, Canada
June 11 June 12	infoShare 2015	Gdańsk, Poland
June 12 June 14	Southeast Linux Fest	Charlotte, NC, USA
June 16 June 20	PGCon	Ottawa, Canada
June 22 June 23	DockerCon15	San Francisco, CA, USA
June 23 June 25	Solid Conference	San Francisco, CA, USA
June 23 June 26	Open Source Bridge	Portland, Oregon, USA
June 23 June 26	Red Hat Summit	Boston, MA, USA
June 25 June 26	Swiss PostgreSQL Conference	Rapperswil, Switzerland
June 25 June 28	Linux Vacation Eastern Europe 2015	Grodno, Belarus
June 26 June 27	Hong Kong Open Source Conference 2015	Hong Kong, Hong Kong
June 26 June 28	FUDCon Pune 2015	Pune, India

If your event does not appear here, please tell us about it.