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.

Misperceptions

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:

[…]
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/xxkb/patches/patch-ab,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/DESCR,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/Makefile,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/PLIST,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/distinfo,v
/home/tonnerre/src/netbsd/cvsroot/pkgsrc/x11/zenity/patches/Attic/patch-aa,v
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