September 2008 Archives

2008-09-21 14:30:36

bouml is behind on NetBSD

On their web site, bouml claims that NetBSD lags behind significantly, having bouml 2.27 packaged.

bouml web site screenshot

This is wrong in two ways. Firstly, NetBSD does not have any packages at all, packages for NetBSD are usually created through the OS independent pkgsrc tree, which, while being developed by the NetBSD foundation, is not especially related to NetBSD.

But more than this, having a short look at pkgsrc reveals the following:

$ pwd
$ make show-var VARNAME=PKGNAME

Evidently, the bouml site is lagging behind significantly? If so, maybe the two sleeping smileys on the site mean just that.

Audit trail

  • 04 Oct 2008 01:20:05: The bouml site has been updated in that respect with the release of bouml 4.6.1, which will however only ship in pkgsrc after the 2008Q3 branch.

Posted by Tonnerre Lombard | Permanent link | File under: programming

2008-09-20 21:19:33

gajim configuration woes

Tonight I finally got enough round tuits to configure my Jabber client Gajim properly. Apart from the base configuration, there are a few options not properly exposed through the configuration interface.

Firstly, every chat window contains a blue bar on top which contains a status logo, the name of the person one's talking to and the avatar of that person. It's huge, blue and in the way. To turn it off, one has to enter the Mozilla-like configuration editor (EditPreferencesAdvancedAdvanced Configuration Editor).

The option to turn off the blue bar is named hide_chat_banner. Also, the option to start all windows in compact mode by default has no ”compact“ at all in its name in case you're considering it: it is named always_hide_chat_buttons.

Posted by Tonnerre Lombard | Permanent link | File under: general

2008-09-17 09:30:00

MacOS 10 security update: cracked up, again

A number of very bizarre Apple specific vulnerabilities was discovered in MacOS 10 and cleaned up in the latest update 2008-003. Apart from some rather old vulnerabilities (well, at least from this year and not from 2005 this time), there were also a number of goodies which only turned up on Apple MacOS systems:

  • Overlong PostScript font names(!) overflow the heap and can lead to arbitrary code execution. Quite a classic one might say.
  • libresolv is updated to the post-CVE-2008-1447 version (see also the analysis). Ok. But the update is not declared as a DNS cache poisoning fix but rather as a performance problem?!
  • By entering LDAP search expressions into the user name field, LDAP users can be enumerated if the MacOS authenticates against Active Directory.
  • Cached credentials are not always flushed when a vnode is recycled. This means that it is not guaranteed that file permissions are actually applied! In fact, it is possible that a file is accessed with the permissions which had been granted on an entirely different file, resulting in loss of permissions or even privilege escalation.
  • A race condition in the login window can be abused to log in as any user without a password. If an account exists on the system which does not have a password, one just needs to log in as that user and log back out and then try to log in as a different user. If the race condition is triggered, then the login will succeed without any password.
  • If an user resets his password using the login window, the old password field is not cleared afterwards. This means that a malicious user can go to the unattended computer where the password was changed and change it again to some password he knows and then log in as the user. (However, it might just be easier to log in with no password.)
  • OpenLDAP is configured to have slapconfig store its password into a world readable file. Apple has quite a history on world readable and writable files, but some people never learn.
  • The PPP passwords are stored in an unencrypted, world-readable file. Well, see above for Apple and world-readable files.
  • Time Machine also stores log files from the backup with world readable permissions.
  • Remote access passwords are truncated to 8 characters. Uhm well. We had that problem as well but fixed it in the early 90s.
  • The Wiki Server mail archive stores mails unsanitized and thus permits cross site scripting. The other Open Source mailing list archives had that too but were fixed roughly 10 years ago.
  • The file permissions are slightly misrepresented with respect to remote access. However, instead of ensuring that remote access permissions are applied as intended, Apple added a note stating that this is not the case.

Have a nice MacOS 10.5 and enjoy the future bugs!

Posted by Tonnerre Lombard | Permanent link | File under: security, programming

2008-09-15 00:46:58

CVE-2008-1447 is still alive - DNSSEC the only way out

With a lot of noise, Dan Kaminsky released the security flaw in the DNS protocol now known as CVE-2008-1447.

The vulnerability is basically a lack of entropy in the XIDs which are used to differenciate between the different responses and to associate them with the corresponding queries. The DNS protocol allows additional information to be submitted in a response which was not asked for, for example if a CNAME is resolved, the corresponding A record which is pointed to may be returned in an additional section. This record is then learned by the DNS resolvers and will be returned on the next request, instead of querying the servers again.

Since the XIDs are rather short, an attacker can send DNS responses with various XIDs in order to poison the DNS cache with arbitrary information. Hosts querying the poisoned host names during the TTL will then receive the fake record and connect to an entirely wrong server.

All my useless advice

Back in 2003, Dan Bernstein already published information about the vulnerability, only making slightly less noise than Kaminsky. According to his assessment, and to public perception, the port randomization performed by DJBDNS already protected against the poisoning attack. Thus, the ISC released a new bind version 9.5.0-P2 which also introduced port randomization, causing all of the various NAT problems already known from the FTP.

However, shortly thereafter, someone put up to actually calculate the odds of the attack with port randomization, and found that the birthday paradoxon actually decreased the complexity of the attack significantly. Shortly thereafter, an exploit for port randomized DNS was released, showing that the port randomization was not a solution to the problem. This leaves DJBDNS vulnerable, too.

DNSSEC – the only way out?

Apparently, only one solution is available so far which really solves the problem: the DNS security extension DNSSEC (RFC4034). DNSSEC signs the zone with SHA1 and an RSA key. The complexity of forging this signature is significantly higher.

The disadvantage of DNSSEC is that all zones must be re-signed either on update (not so problematic) or every 30 days (harder to implement), or otherwise their content will be lost until a new signature is generated. Once one manages to automate this step, however, DNSSEC is really useful.

The ISC has prepared a little guide to help people implementing DNSSEC in 6 minutes – and that's already all that's required. However, DJB hates DNSSEC due to the amout of CPU time used to verify the signature, and thus did not implement it. Salvation can probably be achieved by creating a DNSSEC signed zone and converting it to a djbdns zone using the zone conversion tool.

PowerDNS also supports storage of DNSSEC records, but cannot create them or sign zones in any way. The only way to achieve it is again to sign a bind zone and to convert it. The same applies to MaraDNS: there are simply no DNSSEC tools available.

Spreading the FUD

Nevertheless, various sources are still suggesting that DNSSEC does not help to prevent the attack, and that only source port randomization yielded salvation. Surely, source port randomization does increase the resilience to the attack, but the problem remains unresolved.

Only DNSSEC can provide a definitive solution to the spoofing attacks. Currently, the lack of a trust infrastructure still reduces this protection, since only the host record and the zone signature must be spoofed – which is however already far from feasible.

At the same time, people should stop repeating things which a single source told them – be it Dan Bernstein or Linus Torvalds. No matter if these people are idols, their competence is not universal.

Posted by Tonnerre Lombard | Permanent link | File under: security, network

2008-09-14 19:44:10

Chinese Internet to the world?

The olympic fever was omnipresent during the past 2 monthes. But apparently, some of the ITU as well as some politicians took the notion of an olympic fever way too litterally and started living a feverish dream. While before the olympic summer games, everybody complained about repression of the Chinese and lack of freedom and liberty, very weird voices are raising now after the games.

The target is clear. Berthold Brecht suggested in his Radiotheroie that giving people the possibility to voice their opinion unrevised, universally, will inadvertedly start to develop an opinion of their own and start to escape state supervision. This is what happened on the Internet, but the state authorities are afraid of losing grip on the situation since it was not planned to track down individual members of such a discussion group.

Like Wau Holland said: «Denen ist Brechts Radiotheorie auf die Füsse gefallen, sie haben es nur noch nicht gemerkt.» (”Brecht's Radio theory came to haunt them, they just didn't notice it yet.“)

Since in the meanwhile, the radio theory has indeed been noticed, and the Internet is said to be full of terror (funnily in accordance with Brecht's theory), politicians as well as the ITU are monitoring the situation in China very closely. Why? Because China has managed to establish structures to control the information visible in their part of the Internet. This means that evil terrorism – such as asking for a democratic government – will be noticed and the responsibles can be thrown into prison.

This of course causes a lot of envy among our local politicians. The German CSU politician Uhl recently asked for Chinese-style restricted Internet access in Europe as well: ”If the Chinese can do it, we can do it as well. In that case I take pride in being authoritarian.“

And this is not just a single case from a random politician: the International Telephony Union (ITU) recently set up a working group for tracing back IPs. Evidently, the aim is no longer to convert China into a democracy, but rather to turn the rest of the world into a dictatorship.

Or maybe it's all just an olympic feverish dream?

Posted by Tonnerre Lombard | Permanent link | File under: news, politics

2008-09-14 15:54:19

More notes on Subversion

I recently received a large number of comments concerning my article about our failed attempt to migrate our business processes to Subversion. I found most of them to be the rather useless attempt of a hurt mind to justify its decision; it is not very helpful to say things like ”If you cannot even get such a simple migration right, I would not trust you to do more complicated things.“ Also, criticising the use of french words in the domain name is not really on-topic.


Also, it seems that some people did not read the article at all. Some of the criticism was perfectly explained inside the article itself. For example, someone said that he has the impression that we tried to run our tools developed for CVS against Subversion. However, as it was outlined clearly, we tried to rewrite tools achieving the same result for Subversion, and discovered that some features required to do this simply aren't present in Subversion.

For example, the lack of vendor branches makes it impossible to differenciate between upstream changesets and local changes, making it harder to mirror vendor trees with local changes as required. svk tries to ease this somewhat, but doesn't make it much easier since it cannot detect pulled-up changesets unless they have a special commit message. The lack of vendor specific keywords (e.g. $NetBSD$) has a similar impact.

Some of the comments were actually useful though, be it only in terms of pointing out that some of the aspects were not explained properly. For example, it appears to be true that one can indeed downgrade a single file in a directory to a specific older version. However, the way branches are implemented in Subversion makes it impossible to do this arbitrarily, since files from branches cannot easily be mixed.

cvs2svn – or not

The argument about cvs2svn also remained unresolved so far due to a lack of time. I installed the latest version of cvs2svn 2.1.1nb1 and tried to convert pkgsrc again; this is the end of the output of the process:

Pass 1 complete.
Error summary:
ERROR: A CVS repository cannot contain both /home/tonnerre/src/netbsd/cvsroot/pkgsrc/emulators/gxemul/patches/patch-aa,v and /home/tonnerre/src/netbsd/cvsroot/pkgsrc/emulators/gxemul/patches/Attic/patch-aa,v
Exited due to fatal error(s).

(This is the output of cvs2svn -s /home/tonnerre/src/netbsd/pkgsrc-svn /home/tonnerre/src/netbsd/cvsroot/pkgsrc)

In this light, it seems to me that the claim that cvs2svn simply works is slightly exaggerated.

Subversion checkout segfault

Also, further problems turned up with Subversion during the last week. Trying to check out a subdirectory – i.e. not the Subversion root containing all branches, tags and the trunk – resulted in a segmentation fault of the Subversion client. This problem was reproducible under NetBSD, Fedora Core 9, Ubuntu and Debian Lenny. For some reason, Debian Etch was not affected, but lacked a number of software packages we used in our product.

The segmentation fault occurred in always the same subdirectory. Asking around a bit in the Subversion community, it turned out that this was a rather frequent effect which people reported regularly in various projects. Noone was sure where it originated from, so I decided to check the integrity of the SVN tree using svnadmin verify.

It seems though that svnadmin verify does not verify the tree at all but it attempts instead to check out the specific revisions, crashing and burning in the process. So, since noone of us really has the time to debug all of this, the solution is now to do a full checkout of the entire tree and work on that.

And to all the commentors: please evaluate the usefulness of your comment before hitting the send button. I don't care to hear that you would not hire us to do complicated tasks, we have enough customers who do that already.

Audit trail

  • 24 Sep 2008 10:50:15: I received another mail from the cvs2svn maintainer, claiming that the reason for the problem I'm seeing was that the NetBSD CVS was broken. According to him, this was not a fair comparison. He quoted a suggestion to delete the attic files from the cvs2svn FAQ. I would rather keep them around though as they do contain history.

Posted by Tonnerre Lombard | Permanent link | File under: programming

2008-09-14 13:48:53

Linus' Misconception of the Security Industry

Ever since the (in-)famous Monkey Story, a new anti-security attitude appears to spread among people. Some of the Linus-loyalists started promoting a new attitude of not adhering to the principles of regular security updates and releasing advisories. At the same time, the security industry is worried to see these attitudes fueled by the leader of one of the biggest Open Source communities.

The general perception of security

We had been facing the attitude of security repudiation before from IT consumers, especially in the Windows world there is an attitude of security ignorance. Security patches are not applied regularly because they are perceived as an annoyance rather than a gain.

The biggest enemy of the security consultant is the perception of ”Who would want to attack me anyway? I am not interesting.“ This may have been a valid question in the very early days of computer science, when attacks were conducted by attackers seeking information or kids seeking internet access through wardialing into the mainframes of the planet.

But the type of ”end users“ of security problems has changed significantly. Nowadays, the biggest use case of exploits are spambots, automatted attacking bots which break into any computer in its way in order to use it for spamming other people or conducting denial of service attacks for paid customers. To these bots, the average user with his innocent PC behind a small line becomes as much of a high class target as the rest of the world.

The same applies to server security. The good news is that a lot of the time, attackers no longer search for credit card information (which is nowadays usually no longer received directly by the web shop where people buy their goods but on a server from a trusted credit card service provider who has a real security response team – well, at least some of the time). The bad news is that people who react slowly are going to lose their ability to send mail by ending up on a blacklist.

And so people also don't care that distributions like Ubuntu have (besides other problems) a 3 month lag in terms of security updates, while other comfortable end user distributions like Fedora usually release their patches a couple of hours after the incident.

Where Linus comes in

The unfortunate step in Linus' new-found tendency to security populism is that in this atmosphere of negligence, he fueled the argument that ”security is not important“. Possibly this is not really what he meant. As it has been proven most impressively by Linus' book ”Just for Fun“, we are nowadays facing a large crowd of people who believe every word Linus says and who will just repeat his opinion rather than building their own one. To these people, when Linus says ”security is not important“, security will no longer be of any importance.

Also, Linus has managed to harm the attitude of open disclosure of the various vendors significantly. Since not a lot of vendors really understand the way in which security incidents are handled – which is mostly done by the first distributor who gets involved – Linus' argumentation of giving the script kiddies a headstart appears plausible to them. Thus, security problems are not necessarily disclosed publically anymore.

However, this principle does not necessarily work, especially for the Linux kernel. Due to the development model of the Linux kernel, most of the latest releases of the kernel are behaving very unstable and break features such as suspend to RAM or virtual machines rather frequently. Due to the outlined policy of imposing the burden of fixing these problems on the distributor, that is not really a problem, since the distributors will usually choose older kernel releases and backport fixes and other required features such as new drivers to that version as necessary.

This means however that the vast majority of people is not running the latest Linux kernel release. Some depend on their distributor's release, and some run older releases which ”work for them“, not knowing that there are hidden security holes in that release. Why? Because Linus thinks that security is not important.

At the same time, spammers have an army of people fitting the description of a monkey more closely than the OpenBSD developers. This army harvests the source code and change logs of the Linux kernel for exploitable security problems for use in their spam bots. This is a manpower of cheap chinese and east europeans which most distributors and end users simply don't have. This means that Linus' proclaimed security policy gives script kiddies and spammers a headstart over the end user.

What Linus did not understand

The most convincing of Linus' arguments remains however to the end user, which is, how does one ensure that end users will receive a patch before the spammers had a chance to modify their bots? It appears to an outsider that this problem remains unresolved. This is however not the case. And this is where the masturbating monkey industry security industry comes in.

Just like the software itself, a security advisory also has a release cycle. For the reasons outlined before, this cycle does not even necessarily involve the vendor. The usual procedure is as follows:

Someone discovers a vulnerability and reports it to the vendor. Then, the vendor or that someone contacts a CVE member, e.g. a distributor such as Debian, Redhat, or whomever. Alternatively, the distributor sees the patch for the security problem and picks it up.

Then, the distributor creates a ticket at CVE. Now, all CERTs and distributors of the world are aware of the problem. A patch is developed and the CVE members set a deadline until when all distributions must have the fix. CVE members fix the vulnerability and report their progress through a language called OVAL.

Once every vendor has released a fix, the advisory is made public. Now, the CVE switches state from ”draft“ to ”public“ and becomes readable on the CVE web site. (Before this point, the identifier shows up as assigned but people visiting the site cannot read it.) Distributors release their advisories, and advisoriy outlets such as Secunia pick them up. Only now do spammers have access to the advisory, while end users already have picked up the fix.

So the problem Linus sees with the ”obsessive security industry“ is already solved, all that needs to be done is to report security problems to at least one of the distributors. Starting from this point, Linus could go on taking care of the development cycle.

Posted by Tonnerre Lombard | Permanent link | File under: security