As a visitor here at rgb2r is now moving
to another planet a far-away country, the discussion came up again
how to do PGP key signing properly. Originally, the requestor asked for
passport based signing as done on most of the so-called PGP key signing
parties. However, for the following reasons I will not sign passports
and don't want passport based signatures.
In the normal PGP key signing party based approach, all that is required to obtain a signature is a passport or identity card. The signer verifies that the signee looks like the person on the picture and then signs the key. For this, the signer does not have to know or trust the signee. The signer then submits the key to a key server and the signee can download it from there.
This method allows one to accumulate a lot of signatures over a short time, and to extend the network of signatures very quickly. However, it contains various flaws:
There are probably many more problems this model is arising by its lack of trust dependencies or its focus on the passport as the sole base of trust, but these are the most apparent which came to mind.
The so-called trust signature scheme follows an entirely different dogma. In this scheme, people knowing each other know enough will sign each other's key in order to testify that they are willing to testify that the signee is known as the person he/she claims to be. This of course implies a much greater level of familiarity between the signer and the signee.
Note that in this scheme, it is perfectly valid for the signer to sign a key belonging to a pseudonym — if that's what the signee is known as. That may sound suspicious to a person who's used to attesting passports, but in the end it is much more logical because in the end, the signer attests only what he knows about the other person, without relying on a paper he cannot verify.
Also, some more unrelated improvements come to play. In order to verify UIDs, the signer creates signatures for each individual UID and sends these individually to the mail address in the UID, in an encrypted mail. Then, the signer deletes the signature from the local keychain again. This sounds tedious, but there are good scripts to take care of that, such as, for example, caff from the pgp-tools package.
In this scheme, it is assured that the owner of the UIDs is at least aware of the signature that took place, and can decide whether or not to upload the signatures. On the other hand, a pseudonymous signer can participate without any loss of the trust relationship.
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:
Have a nice MacOS 10.5 and enjoy the future bugs!
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.
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.
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.
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.
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.
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.
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.
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.
After a request from Dan, I upgraded rt to the new version 3.8, and was slightly surprised. Apart from the new interface which finally looks like the MacOS 10 user interface, just like all web applications attempt to these days, and the rich text mail editor — a feature I am hoping never to see in action — it also features a whole new set of user configuration options, and, even better, PGP support.
Also improved is the SPAM filtering support. It is no longer necessary now to prefix rt-mailgate with procmail. Usability is also massively improved, the menu is now on the left again rather than on the top. Only submenus open on top. The annoying thing is though that in menus of a certain depth, the menu bar jumps between top and left for the same menu since the top bar only ever shows the topmost level.
People who are afraid of wearing glasses can now also configure font sizes at will.
So it is time to congratulate Best Practical to their new release, and to look forward to deploying the new PGP feature.
A while ago, a Cross Site Scripting (XSS) vulnerability had been found in CVSweb, as used by the OpenBSD Project.
Now, the name Cross Site Scripting may potentially be very misleading. In fact the problem is that you can insert arbitrary HTML code into the web site. This also means you can fake information displayed in the site; thanks to CSS and related tricks, no JavaScript is required for this anymore. The term Cross Site Scripting actually comes from the one possible scenario where JavaScript code is injected into the web site which can do arbitrary things, even send requests back to the web server of an attacker, e.g. with the password from some login page.
However, this is just one possible scenario. In any case, fake information can be injected into the web site to make it appear as something different.
The correct fix is of course to encode user input properly before displaying it on the web site, just like it's done with user input meant to be used in SQL statements (in SQL injection attacks, this is not done properly). Normally, languages used to design web applications already provide means to encode user input for use in web sites; for example, Perl has encode_entities() in the HTML::Parser package.
(For more information on Cross Site Scripting, please refer to my lecture about common security problems at the Chaos Communication Congress
Rather than to encode the input in question properly and to verify its validity, the OpenBSD people decided to go a very unconventional (and useless) way in fixing the problem. A JavaScript was added to the web site redirecting to a web site stating that JavaScript sucks. This web site goes on to state:
CVSweb takes input to a cgi script to show you source code, which it sanitizes to protect itself. It doesn't care how insecure your web browser is.
Nothing on www.openbsd.org cares about Cross Site Scripting, since we don't use cookies or any form of authentication. However since your web browser will accept script calls in a url that some idiot could send you URL with a script embedded in it to make your browser go somewhere else from a url that starts with www.openbsd.org. Somehow the XSS wankers feel this affects openbsd.org's street cred. Mystifying to me, since if you decide to visit this site with a web browser that does rm -rf / every time your browser sees the word "elephant" - well you just got pwned too.. The problem is your browser.
Of course to remove all special chars in input fields for cvsweb means you can't look for interesting stuff in code. So, someday I might take the time to try to do that, without making cvsweb useless. In the meantime, just turn off javascript when visiting this site, use a browser that doesn't support it, or use the firefox noscript extension and you'll see cvsweb just fine, once you revisit it at http://www.openbsd.org/cgi-bin/cvsweb
The claim that the problem is only in the browser is of course entirely wrong. The web site contains additional information which is not supposed to be there, and the browser cannot tell the difference between wanted and unwanted content. If the input is not properly sanitized, this of course means that the browser will interprete it wrong.
If, for example, you visit the above link with JavaScript disabled, you will still see the headline ”Only 2 Remote bugs“ which clearly does not belong there. The fix is not working.
These days we're living in a world which was stuffed with war, attacks and extremists of all sorts. In the one corner we have the islamic terror which, thanks to series like Sleepers Cell, can now also be enjoyed from the living room. People with the turbans carry around bombs and kill millions of people every day. The youths are sniffing anthrax and have nothing better to do than to segregate themselves from the community only in order to get angry about it and to adhere to extremism.
On the other hand, the communist culture of deportation is still alive. Women of all the world are deported to Moscow, there is not a family in this world who hasn't at least lost one member to them. The deported then have to build nuclear weapons which are specially crafted to attack the United States, the holy grail, the center of the prosper world. For this reason, a protection shield is being established around Poland, Czechia — not Turkey this time, there have been bad experiences with the last attempt.
However, the world of computer security is in no way comparable to it. After a recent security incident of the Baslerzeitung, reports said that “efforts were made to fend off the attacks”. On the bloody morning after, one tin soldier rides away.
In truth, the issue was very simple. The software used by the newspaper was written poorly and allowed to inject additional web site elements (“Javascript Injection”, apparently through SQL). Rather than to line up the tin soldier at the server room, armed with guns to fend off the attackers, the newspaper simply patched their software. Starting from this point, it doesn't matter how many attackers are running against the web site — it is “vaccinated” and no longer vulnerable to the attack.
It is very questionable if the people who write the type of articles quoted by BloggingTom can ever be educated on the issue. It should be clarified to them that computer programs are more comparable to dogs than to countries. Except to the point that there probably are no “badly coded dogs”.
On July 25th I looked a bit into an older Webmin vulnerability, hoping to fix it for the older version of webmin shipped in pkgsrc. However, as it turned out, CVE-2008-0720 affected “almost every single search field». Looking a bit through the search CGIs I quickly found a cross site scripting issue as well as an URL parameter problem, so I looked into Webmin 1.400 for fixes where the problem was supposed to be fixed.
Being the nice person I am, I created a patch and sent it to the webalizer developers. The response was that there was no issue to be resolved since the referrer check would most likely catch the issues already. Thus, I decided to release information about the issue without further verification. The vendor is king, right?
Find the fixes in the current pkgsrc version.
Since agc called for an end of the pkgsrc freeze for the release of pkgsrc-2008Q2 tonight at 21:00 UTC, I had to put in a hackathlon to fix as many security problems as possible. This is an attempt to keep track of them.
pkgsrc has a very old version of WebSVN (1.x, current is 2.0) which comes with a whole bunch of cross-site-scripting issues (see also CVE-2007-3056). In order to fix them during the freeze I had to manually patch WebSVN because there wasn't enough time anymore to ask for a package upgrade of this dimension. Patches were mostly taken from upstream changeset 581. It seems however that both the programming and the English skills of the author are subterranean.
The next item was the silc-client buffer overflow which salo refused to fix for more than a year. I had already created patches for it but they weren't applied for half a year now, so I decided to just go ahead and commit them (especially since wiz suggested so in a prior conversation in April). They basically update the silc-client package from 1.0.4.1 to 1.1.4, which also fixes various character set issues.
Then our modular-xorg-server came with various vulnerabilities, namely those described in freedesktop.org bug 7447 and the release notes of xorg-server 1.4.2. Applying the patches in question fixed the problems, even though an upgrade would not appear to be a bad idea.
For relaxing I took a shot at an old one-liner in balsa. Gnome bug 4743662 has a neat little classic buffer overflow which was easily fixed by adding a range check to the buffer. Unfortunately my 10G slice allocated to packages started to run full here; Gnome is way too large these days.
The next station was the bacula information disclosure: passwords would be passed to various tools through the command line. The ”solution“ the bacula developers came up with was to document the fact. I guess since bacula is mainly a bunch of shell scripts, there isn't really a better way either, so I pulled their documentation.
A maintainer who clearly doesn't take anything seriously is the maintainer of vobcopy. I fixed an insecure temp file creation issue but it was rather hard to parse his changelog with all the smileys.
Perdition IMAP was another easy one; a buffer overflow check in IMAP command tag deparsing had to be rearranged to remain effective if the tag contained a NULL byte.
An encounter I would rather have avoided was pear-MDB2. That little beast has an information disclosure vulnerability in the structure of the respective drivers, so they all have to be updated individually. This was a rather tedious task, and in addition to that it was PHP code...
Worse than that, the package even shipped with an XML file containing MD5 sums of all source files et cetera. This made it even harder to patch since the package.xml file had to be updated as well with every change, and it was a downloaded file.
The Z shell featured a broken difflog script which created temporary files with predictable names. Most distributions simply removed the file from the distribution, but I decided to simply throw in a bit of File::Temp love. The result worked judging from my first small tests.
After I told Gendalia a while ago that she should fix OpenAFS, I did it myself now. The fix consisted in an upgrade to a newer version.
The last one handled today was wyrd, a simple privilege escalation in the ocaml code. The patch from Debian bug 466382 applied well.
Some pkgsrc-wip packages needed TODO entries, among those were jetty, e2fsprogs and Radiator.
A number of tickets were also simply outdated and had to be closed. The result of the day:
| Open tickets | Stalled tickets | |
|---|---|---|
| Before | 113 | 27 |
| After | 69 | 3 |
I also left some crazy patterns, not in the sand but in the mailing list archives.
The current stats in the (not serious) pkgsrc-security contest are:
| salo | tonnerre | adrianp | ghen | wiz | tron | joerg | 36 others |
|---|---|---|---|---|---|---|---|
| 2038 | 334 | 238 | 153 | 107 | 92 | 63 | 327 |
Welcome in life, pkgsrc-2008Q2!
A lot of confusion has turned up about the OpenSSL insecure PRNG vulnerability in Debian and related systems. This is an attempt to clear these up.
All distributions which pulled their OpenSSL changes directly from Debian. Those are namely:
Debian Etch and Lenny, Ubuntu/Kubuntu/Xubuntu and related, grml, Knoppix and all living customizations and Univention UCS 2.0. Other Linux distributions may also be affected.
Known not to be affected are: Fedora, Debian Sarge, NetBSD, OpenBSD, FreeBSD, DragonFlyBSD, MirBSD, Gentoo Linux, Univention UCS 1.x, Red Hat Enterprise Linux, OpenSuSE, SuSE Linux Enterprise, CentOS, pfSense, m0n0wall, Sun Solaris 10 and prior and OpenSolaris.
Due to a slightly misguided valgrind warning patch, the only “random” element used in key generation and other random number generation processes by Debian was the process ID. Since typical process IDs under Linux range from 0 to 65'535, there were only 65'536 possible different keys generated by the OpenSSL toolchain, also including SSH.
This means specificially that an attacker needs only 65'536 attempts to bruteforce a key generated by any Debian tool during this period of time. The impact of this depends on the usage of the key: for SSH user keys, it means that an attacker can impersonate the affected user and log in as the affected user to any system where the key is in the authorized_keys file. For keys used for certification and encryption, such as SSH host keys and SSL certificates, an attacker can impersonate the affected SSH or web server, and can potentially read currently running and recorded sessions, depending on the procedure used for session key establishment.
Debian and Ubuntu have released tools for key analysis which scan for patterns of the vulnerable keys by connecting to named hosts and looking into user's home directories for authorized_keys files which contain the patterns. An updated version of OpenSSH for Debian and Ubuntu now ships with a tool to automatically discover and refuse the vulnerable keys.
The first point is of course to immediately update the affected packages if you use a Debian derived system. Then, generate new SSH keys and replace them on all systems where your old SSH keys are located. Replace them as well on the servers of this nasty customer who left for the concurrence – imagine what would happen if he found out that you left a vulnerable SSH key on his host and that his host was compromitted by your negligence.
All affected OpenSSL certificates should also be revoked immediately. Generate new certificates and let them be signed and re-issued through your CA. Commercial CAs should let you reissue the certificate with the same Subject until the end of the certification period you paid up to. Please note that revokation is a critical step here, otherwise people might still impersonate your old certificate which might, after all, still be valid.
Then make sure your infrastructure was not taken over by botnets through an insecure SSH key. Check for rootkits as well while you're at it. If your log host is affected, tough luck.
Yes, this item requires your immediate attention as there are already botnets out there which search for accounts with vulnerable SSH keys. The question is not “Does someone care about me little Internet user?” — these bots are out to compromise hosts and to send SPAM and malware to other hosts. They don't care if you are an attractive target, they attack anything they can find and try to send SPAM with it.
Yes. On a Debian system, your private key was not safe during the last 2 years. The system may have been compromitted during that time, or someone may even only have been eavesdropping your communication and have gained knowledge about your SSH key. You should definitely consider it compromitted.
This depends. If your key is an RSA key, it is not compromitted simply by putting the public key onto a server and authenticating against it. The SSH 2.0 protocol, as described in RFCs 4252 and 4253, part of the token being signed as challenge by the user is the “session identifier”, which is a hash from the key exchange. This effectively prevents replay attacks of authentication processes done using a non-vulnerable SSH key, because the random material used as challenge is not only controlled by the vulnerable SSH host, but also by the non-vulnerable client. Thus, the data your SSH key has to sign as a challenge is not vulnerable to the weak PRNG of the SSH server, and thus cannot compromise your key.
This is however not true for DSA keys. DSA has a weakness when used in the Diffie-Hellmann key exchange process, rendering it basically uneffective. If the attacker gets hold of the random number used by the Debian SSH server in the key exchange process, this can be used to calculate the private DSA key from the public key with a complexity of 216, being 65'536.
Special thanks for this goes to Steven M. Bellovin, who took the time to go through an analysis of this entire process with me and to clear up my misunderstandings about the OpenSSH challenge-response procedure.