Report – FAD 1 Nov 2014 – theme security


Last weekend I participated in a Fedora Activity Day(FAD) aimed at introducing participants to the Fedora Security Team, its mission and activities. This post is a retrospective review of the day and lessons learned.

Day began with me introducing the participants to the Fedora Security Team, the current security features offered by Fedora and why we need to do much more to make sure that Fedora users are secure by default.

    See ->

This introductory talk was followed by triaging of open security bugs; There are more than 500 of them. Security bugs are marked by Keywords: Security. It means the said bug might have security implications and could facilitate unauthorised/undue access to users. I started triaging with the oldest bugs to figure out why were they open. This in turn leads us to see possible lapses which allow such bugs to remain unattended for longer than they should be.

Why do security bugs stay open and unattended…?

  • Appropriate fixes are unavailable, ie. patches do not exist at all. BZ#864897
  • Appropriate fixes are available, but the maintainer does not know. BZ#782620, BZ#851773, BZ#887451
  • Appropriate fixes are available, but the package is due its retirement, thus ignored BZ#838162. The package is _not_ retired.

These bugs were unattended for more than 2 years and have severe implications like Man in The Middle (MiTM) attack, Arbitrary Code Execution(ACE) and Denial of Service(DoS).

How do we address these lapses…?

The 2’nd and 3’rd case above, wherein the due patches are available, I think we can address them by hounding the maintainers with periodic ‘[NEEDINFO]’ pings till the time they push an update. It won’t be as easy as it sounds, but is an option nonetheless.

It is the 1st case, wherein the due patches are not available, that intrigues and interests me more. So, why aren’t these patches made available? One of the comment BZ#864897#c12 says the fix requires a functionality from OpenSSL 1.1 to be back ported to currently used versions – OpenSSL 1.0.1i. I opened a bug against OpenSSL BZ#1160172, but it was closed(deferred) saying it is not likely to happen any time soon. So the only option is for application to do the TLS certificate validation by itself, which the package maintainer is unable to do. This leads me to an another _grave_ concern that has been cropping up in recent times ie. – dwindling contributor base for some of the widely used & deployed FOSS projects.

This was discussed at Linuxcon last year or the year before; As the average age of subsystem maintainers is rising towards late 30s. At this stage they are likely to be occupied with families and other things in life and hence are unable to spend as much time on their projects. Siddhesh recently mentioned that becoming a parent could drop your productive time by as much as 30%. In yet another conversation I heard this applies to OpenSSL too. Upstream OpenSSL maintainers are well in their 40s and are a close-knit group, which is not welcoming enough to the new entrants(reminds me of Mr drepper and glibc few years ago).

It is high time that we(Fedora) start taking measures towards grooming new contributors and package maintainers. In corporate parlance it is known as succession planning. It should be done by each individual project leader. As for the bugs and tasks that I come across, I have started posting them to the dgplug students list

    See ->

It has a lesser hit ratio, but I hope it improves going forward. If not, we’ll keep dousing the same fire again and again.

    See -> Cybersecurity experts discover lapses in Heartbleed bug fix.

Fedora Activity Day – 1 Nov 2014 – theme Security


    See ->

On 1’st Nov 2014, we plan to host a Fedora Activity Day(FAD) focused at assessing the state of Security in Fedora distribution. The day would start with a brief introduction to Fedora security and progress towards collective security bug triage and other activities. If you are in Pune(India) or plan to be here on 1st Nov, please feel free to drop in and join the action. Note:- we have limited capacity(=~25) for participants, please do register on the wiki page above.

Not too long ago, the Fedora Security Team came to be with the sole intention to improve the state of security in Fedora distribution. Primary goal was to help triage the security bugs and spread awareness.

    See ->

But in the light of the recent upheavals caused by the deadly and the viral security dynamite of the Heartbleed, the Shellshock, and the POODLE[1] flaws, it is only logical to brace ourselves and work towards greater efforts to make Fedora _secure_ by default. Many distributions have taken focused efforts towards this end for decades now,

    Ex ->

Idea is to increase the number of eye balls looking at the Fedora security so that the flaws become shallow. And your poodle’s hearts are saved from bleeding caused by the shocks that are still hidden in the future.

Hope to see you there. 🙂


New-DJBDNS 1.05.9


I feel extremely happy to announce that a new release, version 1.05.9, of the N-DJBDNS is out and available for download

    at ->

(For the uninitiated) N-DJBDNS is the brand new, totally revamped and renovated version of the djbdns. It has lots of great features which make it all worth it to give it a try. 🙂

This release includes three major features along with the numerous enhancements to the code base, which significantly improve the quality of the software. The three major features are

* Human readable logging support in the root server: continuing the changes which began in the last release, this release concludes the logging changes by unifying the two loggers, one of root servers’ & another of dnscache(8) resolver’s into one. Thus enabling consistent, human readable log structure and format across all servers. It greatly helps to remove redundant code base. It significantly eases the task of maintenance.

* Xinetd(8) and Systemd(1) support for axfrdns(8): The DNS zone transfer server axfrdns(8) was broken[#3], because it used to depend on the ‘tcpserver’ for listening on its behalf. This issue is fixed with the new configurations which enable the axfrdns(8) server to work with Xinetd(8) & Systemd(1) services. Thanks to Jason Clark & Edwin Eefting for helping with the comprehensive reviews and testing.

* DNS(or domain) Block List in dnscache(8): This I think is the most important feature of this release. DNS Block List is a list of domain names which are to be blocked by the resolver. Client requests querying for such domains are dropped by the server. This would add an additional layer of security for DNS clients and also help to reduce malicious traffic.

DNS block list is a ‘cdb’ database created using tinydns-data(1) tool. tinydns-data(1) creates the ‘cdb’ database from a ‘data’ file. List the malicious domain names in this ‘data’ file as generic domain records, one on each line, as:

Number ‘284’ is not used, it can be any integer between 256..65535. tinydns-data(1) would create a ‘data.cdb’ database from this ‘data’ file. Rename ‘data.cdb’ to ‘dnsbl.cdb’, for that is the file read by dnscache(8) resolver.

    $ mv data.cdb dnsbl.cdb

dnscache(8) reads ‘dnsbl.cdb’ from its working($ROOT) directory defined in its configuration file. For starters, I created a domain list from the data set. Being a set of phishing URLs, the list has few false positives though.

    $ python -m json.tool online-valid.json | grep -i ‘”url”: “http’ –    \
         | cut -d’/’ -f3 | sort | uniq | awk -e ‘{ print “:”$0″:284::::”; }’ | tee data

Hope you find it helpful. 🙂