Fuzzing is easy
Sunday, September 7. 2008, 19:17
I recently played around with the possibilities of fuzzing. It's a simple way to find bugs in applications.
What you do: You have some application that parses some kind of file format. You create lots (thousands) of files which have small errors. The simplest approach is to just change random bits. If the app crashes, you've found a bug, it's quite likely that it's a security relevant one. This is especially crucial for apps like mail scanners (antivirus), but pretty much works for every app that parses foreign input. It works especially well on uncommon file formats, because their code is often not well maintained.
My fuzzing tool of choice is zzuf.
I am impressed and a bit shocked how easy it is to find crashers and potential overflows in common, security relevant applications. My last discovery was a crasher in the chm parser of clamav.
What you do: You have some application that parses some kind of file format. You create lots (thousands) of files which have small errors. The simplest approach is to just change random bits. If the app crashes, you've found a bug, it's quite likely that it's a security relevant one. This is especially crucial for apps like mail scanners (antivirus), but pretty much works for every app that parses foreign input. It works especially well on uncommon file formats, because their code is often not well maintained.
My fuzzing tool of choice is zzuf.
I am impressed and a bit shocked how easy it is to find crashers and potential overflows in common, security relevant applications. My last discovery was a crasher in the chm parser of clamav.
Hash-collissions in real world scenarios
Tuesday, April 29. 2008, 21:44
I just read an article about the recent wordpress vulnerability (if you're running wordpress, please update to 2.5.1 NOW), one point raised my attention: The attack uses MD5-collisions.
I wrote some articles about hash collisions a while back. Short introduction: A cryptographic hash-function is a function where you can put in any data and you'll get a unique, fixed-size value. »unique« in this case scenario means that it's very hard to calculate two different strings matching to the same hash value. If you can do that, the function should be considered broken.
The MD5 function got broken some years back (2004) and it's more or less a question of time when the same will happen to SHA1. There have been scientific results claiming that an attacker with enough money could easily create a supercomputer able to create collisions on SHA1. The evil thing is: Due to the design of both functions, if you have one collision, you can create many more easily.
Although those facts are well known, SHA1 is still widely used (just have a look at your SSL connections or at the way the PGP web of trust works) and MD5 isn't dead either. The fact that a well-known piece of software got issues depending on hash collisions should raise attention. Pretty much all security considerations on cryptographic protocols rely on the collision resistance of hash functions.
The NIST plans to define new hash functions until 2012, until then it's probably a safe choice to stick with SHA256 or SHA512.
I wrote some articles about hash collisions a while back. Short introduction: A cryptographic hash-function is a function where you can put in any data and you'll get a unique, fixed-size value. »unique« in this case scenario means that it's very hard to calculate two different strings matching to the same hash value. If you can do that, the function should be considered broken.
The MD5 function got broken some years back (2004) and it's more or less a question of time when the same will happen to SHA1. There have been scientific results claiming that an attacker with enough money could easily create a supercomputer able to create collisions on SHA1. The evil thing is: Due to the design of both functions, if you have one collision, you can create many more easily.
Although those facts are well known, SHA1 is still widely used (just have a look at your SSL connections or at the way the PGP web of trust works) and MD5 isn't dead either. The fact that a well-known piece of software got issues depending on hash collisions should raise attention. Pretty much all security considerations on cryptographic protocols rely on the collision resistance of hash functions.
The NIST plans to define new hash functions until 2012, until then it's probably a safe choice to stick with SHA256 or SHA512.
gajim with otr encryption
Monday, April 21. 2008, 02:21
In the instant messaging world, encryption is a bit of a problem. There is no single standard that all clients share, mostly two methods of encryption are out there: pgp over jabber (as defined in the xmpp standard) and otr.Most clients only support either otr (pidgin, adium) or pgp (gajim, psi), for a long time I was looking for a solution where both methods work. psi has otr-patches, but they didn't work when I tried them. kopete also has an otr-plugin, but I've not tested that yet.
Today I found that there is an otr-branch of gajim, which is my everyday client, so this would be great. As you can see on the picture, it seems to work on a connection with an ICQ user using pidgin.
I've created some ebuilds in my overlay (the code is stored in bazaar, I've copied the bzr eclass from the desktop effects overlay):
svn co https://svn.hboeck.de/overlay
Kassenzettel
Friday, April 18. 2008, 21:05
Normalerweise versuche ich aus Datenschutzgründen, nach Möglichkeit mit Bargeld und nicht mit EC-Karte zu bezahlen. Gestern jedoch merkte ich erst im Laden, dass ich viel zu wenig Bargeld bei mir hatte. Also doch mit Karte.
Beim rausgehen warf ich ein Stück überflüssige Verpackung gleich in den Müll und wollte schon mit dem Kassenzettel ebenso verfahren, hielt jedoch kurz inne. Steht da was möglicherweise sensibles drauf? Geschaut, tatsächlich, BLZ, Kontonummer (kein Name, sonst wär's noch problematischer). Ich weiss nicht ob das üblich ist, werde aber in Zukunft darauf achten.
Welche möglicherweise spannenden Datensätze man generieren könnte, durch schlichtes Wühlen in den Papierkörben vor großen Geschäften, das überlasse ich der Phantasie meiner Leser.
Beim rausgehen warf ich ein Stück überflüssige Verpackung gleich in den Müll und wollte schon mit dem Kassenzettel ebenso verfahren, hielt jedoch kurz inne. Steht da was möglicherweise sensibles drauf? Geschaut, tatsächlich, BLZ, Kontonummer (kein Name, sonst wär's noch problematischer). Ich weiss nicht ob das üblich ist, werde aber in Zukunft darauf achten.
Welche möglicherweise spannenden Datensätze man generieren könnte, durch schlichtes Wühlen in den Papierkörben vor großen Geschäften, das überlasse ich der Phantasie meiner Leser.
Wordpress mass hacks for pagerank
Thursday, April 10. 2008, 02:44
Today heise security brought a news that a growing number of old wordpress installations get's misused by spammers to improve their pagerank. I've more or less waited for something like that, because it's quite obvious: If you have an automated mechanism to use security holes in a popular web application, you can search for them with a search engine (google, the mighty hacktool) and usually it's quite trivial to detect both application and version.
This isn't a wordpress-thing only, this can happen to pretty much every widespread web application. Wordpress had a lot of security issues recently and is very widespread, so it's an obvious choice. But other incidents like this will follow and future ones probably will affect more different web applications.
The conclusion is quite simple: If you're installing a web application yourself, you are responsible for it! You need to look for security updates and you need to install them, else you might be responsible for spammers actions. And there's no »nobody is interested in my little blog«-excuse, as these are not attacks against an individual page, but mass attacks.
For administrators, I wrote a little tool a while back, where I had such incidents in mind: freewvs, it checks locally on the filesystem for web applications and knows about vulnerabilities, so it'll tell you which web applications need updates. It already detects a whole bunch of apps, while more is always better and if you'd like to help, I'd gladly accept patches for more applications (the format is quite simple).
With it, server administrators can check the webroots of thier users and nag them if they have outdated cruft laying around.
This isn't a wordpress-thing only, this can happen to pretty much every widespread web application. Wordpress had a lot of security issues recently and is very widespread, so it's an obvious choice. But other incidents like this will follow and future ones probably will affect more different web applications.
The conclusion is quite simple: If you're installing a web application yourself, you are responsible for it! You need to look for security updates and you need to install them, else you might be responsible for spammers actions. And there's no »nobody is interested in my little blog«-excuse, as these are not attacks against an individual page, but mass attacks.
For administrators, I wrote a little tool a while back, where I had such incidents in mind: freewvs, it checks locally on the filesystem for web applications and knows about vulnerabilities, so it'll tell you which web applications need updates. It already detects a whole bunch of apps, while more is always better and if you'd like to help, I'd gladly accept patches for more applications (the format is quite simple).
With it, server administrators can check the webroots of thier users and nag them if they have outdated cruft laying around.
Blog-Spam abusing XSS
Thursday, March 27. 2008, 13:15
I got some spam in the comment fields of my blog that raised my interest.
Some sample how they looked like:
http://www.unicef.org/voy/search/search.php?q=some+advertising%3Cscript%3Eparent%2elocation%2ereplace%28%22http%3A%2F%2Fgoogle%2ede22%29%3C%2Fscript%3E
I've replaced the forwarding URL and the advertising words (cause I don't want to raise interest on spammers pages). I got several similar spam comments the following days all with the same scheme. Using a Cross Site Scripting vulnerability, mostly on pages that might raise trust to forward to a medical selling page.
This is probably a good reason why XSS should be fixed, no matter what attack vectors there are. It can always be used by spammers to use your pages fame / authority to advertise their services. Same goes for redirectors or frame injections. Some where already reported at some public place (for the above see here). I've re-reported them all, but got just one reply by a webmaster who fixed it. True reality on the internet today, even webmasters of famous public organizations don't seem to care about internet security.
For the record, the others:
http://adventisthealth.org/utilities/search.asp?Yider=<script>alert(1)</script>
http://www.loc.gov/rr/ElectronicResources/search.php?search_term=<script>alert(1)</script>
And thanks to iconfactory, they fixed their XSS.
Some sample how they looked like:
http://www.unicef.org/voy/search/search.php?q=some+advertising%3Cscript%3Eparent%2elocation%2ereplace%28%22http%3A%2F%2Fgoogle%2ede22%29%3C%2Fscript%3E
I've replaced the forwarding URL and the advertising words (cause I don't want to raise interest on spammers pages). I got several similar spam comments the following days all with the same scheme. Using a Cross Site Scripting vulnerability, mostly on pages that might raise trust to forward to a medical selling page.
This is probably a good reason why XSS should be fixed, no matter what attack vectors there are. It can always be used by spammers to use your pages fame / authority to advertise their services. Same goes for redirectors or frame injections. Some where already reported at some public place (for the above see here). I've re-reported them all, but got just one reply by a webmaster who fixed it. True reality on the internet today, even webmasters of famous public organizations don't seem to care about internet security.
For the record, the others:
http://adventisthealth.org/utilities/search.asp?Yider=<script>alert(1)</script>
http://www.loc.gov/rr/ElectronicResources/search.php?search_term=<script>alert(1)</script>
And thanks to iconfactory, they fixed their XSS.
Gedanken zur Onlinedurchsuchung
Wednesday, February 27. 2008, 23:48
Heute früh hat das Bundesverfassungsgericht geurteilt, das ganze so, dass jeder sich ein bißchen als Sieger fühlen darf. Grob lautet das Urteil, dass Onlinedurchsuchungen zwar prinzipiell zulässig sind, aber nur unter extrem eingeschränkten Bedingungen und mit Richtervorbehalt. Letzterer wird leider allzu oft als Allheilmittel gegen Mißbrauch gesehen, was sich dummerweise mit der Realität äußerst selten deckt.
Das Problem, was ich bei Diskussionen über die sogenannte »Onlinedurchsuchung« erlebe, ist, dass meine Hauptbedenken erst da anfangen, wo das technische Verständnis der meisten anderen (insbesondere auch der entscheidenden Politiker) längst aufgehört hat. Ich gebe mich heute dem Versuch hin, selbige Bedenken auszuformulieren, ohne alle Nicht-Techies abzuhängen.
Zunächst mal muss man ungefähr begrifflich fassen, was »Onlinedurchsuchung« sein soll. Im Regelfall meint man damit, dass in ein fremdes Computersystem eingedrungen werden soll und dort Daten geholt oder manipuliert werden (Detailunterscheidungen in Datenbeschlagnahmung, Quellen-TKÜ o.ä. unterlasse ich jetzt mal). Nun ist der vielfach herzitierte Vergleich mit der Hausdurchsuchung ein problematischer, weil Computer üblicherweise keine virtuelle »Tür« haben. In der Realwelt wird eine Tür eben eingetreten oder das Schließsystem anderweitig umgangen (ja, es gibt elegantere Wege, die kenn ich auch). Sowas ist jetzt erstmal bei einem Computersystem nicht zwangsweise möglich, weil es nichts gibt, was man im Zweifel mit roher Gewalt (Türe) überwinden kann.
Um dennoch in ein System einzudringen, macht man sich üblicherweise Sicherheitslücken in Systemen zu Nutze. Und hier kommen wir meiner Ansicht nach zum Kern des Problems: Nämlich der Umgang mit dem Wissen über Sicherheitslücken. Im Hacker-Slang unterscheidet man manchmal zwischen Whitehats (»gute« Hacker) und Blackhats (»böse« Hacker). Whitehats sind solche, die ihr erlangtes Wissen über Sicherheitslücken lediglich dazu nutzen, diese zu beheben, indem sie etwa den Hersteller des Systems/der Software informieren und die Lücke anschließend publizieren. Blackhats sind solche, die die Kenntnis über Sicherheitslücken nutzen, um in fremde Systeme einzudringen.
Nun haben wir den etwas ungewohnten Fall, dass der Staat als Blackhat agieren will, sprich Sicherheitslücken NICHT publiziert, weil er sie für Onlinedurchsuchungen nutzen möchte. An diesem Punkt wird auch klar, dass das Thema eben nicht nur für die von einer Durchsuchung Betroffenen relevant ist, sondern für praktisch jeden. Woher der Staat diese Informationen bekommt, wäre eine eigene spannende Frage.
Nun ergeben sich daraus einige interessante Folgefragen. Ab und an kommt es ja vor, dass ein Computervirus mal eben das halbe Wirtschaftsleben lahmlegt (vor nicht allzu langer Zeit wurde ein Großteil der Rechner der Deutschen Post befallen). Bei zukünftigen derartigen Fällen wird man, nicht zu Unrecht, die Frage stellen, ob ein solcher Vorfall möglicherweise hätte verhindert werden können, hätte der Staat sein Wissen über Sicherheitsprobleme mit dem Rest der Menschheit geteilt. Was das für eventuelle Schadensersatzansprüche bedeutet, damit mag sich ein ambitionierter Jurist vielleicht einmal beschäftigen.
Ein weiterer, möglicherweise durchaus nicht unspannender Aspekt, der sich auftut: Der Staat begibt sich hier auf ein Gebiet, auf dem gewisse Regeln nicht unbedingt so gelten wie andernorts. Um oben genanntes Beispiel einer Hausdurchsuchung heranzuziehen, dürfte es in aller Regel so sein, dass ein Staat eine Hausdurchsuchung durchsetzen kann, egal in welcher Form sich die Hausinsassen wehren, aus dem simplen Grund, dass der Staat ein übermächtiges Repertoire an Gewaltmitteln zur Verfügung hat (zumindest gilt derartiges für westeuropäische Industrieländer).
Nun begibt sich der Staat in Außeinandersetzungen, wo dieser Vorteil plötzlich schwindet. Was der Staat hier tut, darauf hat er kein Monopol. »Onlinedurchsuchung«, das kann der Spammer, der Terrorist oder der Feierabendhacker möglicherweise genau so gut.
Das Problem, was ich bei Diskussionen über die sogenannte »Onlinedurchsuchung« erlebe, ist, dass meine Hauptbedenken erst da anfangen, wo das technische Verständnis der meisten anderen (insbesondere auch der entscheidenden Politiker) längst aufgehört hat. Ich gebe mich heute dem Versuch hin, selbige Bedenken auszuformulieren, ohne alle Nicht-Techies abzuhängen.
Zunächst mal muss man ungefähr begrifflich fassen, was »Onlinedurchsuchung« sein soll. Im Regelfall meint man damit, dass in ein fremdes Computersystem eingedrungen werden soll und dort Daten geholt oder manipuliert werden (Detailunterscheidungen in Datenbeschlagnahmung, Quellen-TKÜ o.ä. unterlasse ich jetzt mal). Nun ist der vielfach herzitierte Vergleich mit der Hausdurchsuchung ein problematischer, weil Computer üblicherweise keine virtuelle »Tür« haben. In der Realwelt wird eine Tür eben eingetreten oder das Schließsystem anderweitig umgangen (ja, es gibt elegantere Wege, die kenn ich auch). Sowas ist jetzt erstmal bei einem Computersystem nicht zwangsweise möglich, weil es nichts gibt, was man im Zweifel mit roher Gewalt (Türe) überwinden kann.
Um dennoch in ein System einzudringen, macht man sich üblicherweise Sicherheitslücken in Systemen zu Nutze. Und hier kommen wir meiner Ansicht nach zum Kern des Problems: Nämlich der Umgang mit dem Wissen über Sicherheitslücken. Im Hacker-Slang unterscheidet man manchmal zwischen Whitehats (»gute« Hacker) und Blackhats (»böse« Hacker). Whitehats sind solche, die ihr erlangtes Wissen über Sicherheitslücken lediglich dazu nutzen, diese zu beheben, indem sie etwa den Hersteller des Systems/der Software informieren und die Lücke anschließend publizieren. Blackhats sind solche, die die Kenntnis über Sicherheitslücken nutzen, um in fremde Systeme einzudringen.
Nun haben wir den etwas ungewohnten Fall, dass der Staat als Blackhat agieren will, sprich Sicherheitslücken NICHT publiziert, weil er sie für Onlinedurchsuchungen nutzen möchte. An diesem Punkt wird auch klar, dass das Thema eben nicht nur für die von einer Durchsuchung Betroffenen relevant ist, sondern für praktisch jeden. Woher der Staat diese Informationen bekommt, wäre eine eigene spannende Frage.
Nun ergeben sich daraus einige interessante Folgefragen. Ab und an kommt es ja vor, dass ein Computervirus mal eben das halbe Wirtschaftsleben lahmlegt (vor nicht allzu langer Zeit wurde ein Großteil der Rechner der Deutschen Post befallen). Bei zukünftigen derartigen Fällen wird man, nicht zu Unrecht, die Frage stellen, ob ein solcher Vorfall möglicherweise hätte verhindert werden können, hätte der Staat sein Wissen über Sicherheitsprobleme mit dem Rest der Menschheit geteilt. Was das für eventuelle Schadensersatzansprüche bedeutet, damit mag sich ein ambitionierter Jurist vielleicht einmal beschäftigen.
Ein weiterer, möglicherweise durchaus nicht unspannender Aspekt, der sich auftut: Der Staat begibt sich hier auf ein Gebiet, auf dem gewisse Regeln nicht unbedingt so gelten wie andernorts. Um oben genanntes Beispiel einer Hausdurchsuchung heranzuziehen, dürfte es in aller Regel so sein, dass ein Staat eine Hausdurchsuchung durchsetzen kann, egal in welcher Form sich die Hausinsassen wehren, aus dem simplen Grund, dass der Staat ein übermächtiges Repertoire an Gewaltmitteln zur Verfügung hat (zumindest gilt derartiges für westeuropäische Industrieländer).
Nun begibt sich der Staat in Außeinandersetzungen, wo dieser Vorteil plötzlich schwindet. Was der Staat hier tut, darauf hat er kein Monopol. »Onlinedurchsuchung«, das kann der Spammer, der Terrorist oder der Feierabendhacker möglicherweise genau so gut.
Politics, Security |
Comments (3)
| Trackbacks (0)
Defined tags for this entry: bundestrojaner, bundesverfassungsgericht, onlinedurchsuchung, security, sicherheit, überwachung
Manually decrypting S/MIME mails
Tuesday, February 26. 2008, 21:05
I recently took the new CAcert assurer test. Afterwards, one has to send a S/MIME-signed mail to get a PDF-certificate.
Having the same problem like Bernd, the answer came in an RC2-encrypted S/MIME-mail. I'm using kmail, kmail uses gpgsm for S/MIME and that doesn't support RC2.
While this opens some obvious questions (Why is anyone in the world still using RC2? Why is anyone using S/MIME at all?), I was able to circumvent that without the hassle of installing thunderbird (which was Bernd's solution).
openssl supports RC2 and can handle S/MIME. And this did the trick:
It needed the full mail, which took me a while, because I first tried to only decrypt the attachment.
Having the same problem like Bernd, the answer came in an RC2-encrypted S/MIME-mail. I'm using kmail, kmail uses gpgsm for S/MIME and that doesn't support RC2.
While this opens some obvious questions (Why is anyone in the world still using RC2? Why is anyone using S/MIME at all?), I was able to circumvent that without the hassle of installing thunderbird (which was Bernd's solution).
openssl supports RC2 and can handle S/MIME. And this did the trick:
openssl smime -decrypt -in [full mail] -inkey sslclientcert.key
It needed the full mail, which took me a while, because I first tried to only decrypt the attachment.
Cross Site Scripting (XSS) in the backend and in the installer
Tuesday, February 26. 2008, 14:23
I want to give some thoughts about some more advanced XSS-issues based on two vulnerability announcements I recently made.
First is backend XSS. I think this hasn't been adressed very much, most probably all CMS have this issue. If you have a CMS-System (a blog is also a CMS system in this case) with multiple users, there are various ways where users can XSS each other. The most obvious one is that it's common practice that a CMS gives you some way to publish raw html content.
Assuming you have a blog where multiple users are allowed to write articles. Alice writes an article, Eve doesn't like the content of that article. Eve can now write another article with some JavaScript adjusted to steal Alice's cookie. As soon as Alice is logged in and watches the frontpage with Eve's article, her cookie get's stolen, Eve can hijack her account and manipulate her articles.
Solution is not that simple. To prevent the XSS, you'd have to make sure that there's absolutely no way to put raw html code on the page. Serendipity for example has a plugin called trustxss which should do exactly that, though there are many ways to circumvent that (at least all I found should be fixed in 1.3-beta1, see advisory here: CVE-2008-0124). All fields like username, user-information etc. need to be escaped and it should be the default that users aren't allowed to post html. If a superuser enables html-posting for another user, he should be warned about the security implications.
A quite different way would be separating front- and backend on different domains. I don't know of any popular CMS currently doing that, but it would prevent a lot of vulnerabilities: The website content is, e.g., located on www.mydomain.com, while the backend is on edit.mydomain.com. It would add complexity to the application setup, especially on shared hosting environments.
Second issue is XSS/CSRF in the installer. I'm not really sure how I should classify these, as an open installer most probably has more security implications than just XSS. I recently discovered an XSS in the installer of moodle (CVE-2008-0123) which made me think about this.
I thought of a (real) scenario where I was sitting in a room with a group, discussing that we need a webpage, we would take Domain somedomain.de and install some webapp (in this case MediaWiki, but there I found no such issues) there. I suddenly started implementing that with my laptop. Other people in the room hearing the discussion could send me links to trigger some kind of XSS/CSRF there. This probably isn't a very likely scenario, but still, I'd suggest to prevent XSS/CSRF also in the installer of web applications.
First is backend XSS. I think this hasn't been adressed very much, most probably all CMS have this issue. If you have a CMS-System (a blog is also a CMS system in this case) with multiple users, there are various ways where users can XSS each other. The most obvious one is that it's common practice that a CMS gives you some way to publish raw html content.
Assuming you have a blog where multiple users are allowed to write articles. Alice writes an article, Eve doesn't like the content of that article. Eve can now write another article with some JavaScript adjusted to steal Alice's cookie. As soon as Alice is logged in and watches the frontpage with Eve's article, her cookie get's stolen, Eve can hijack her account and manipulate her articles.
Solution is not that simple. To prevent the XSS, you'd have to make sure that there's absolutely no way to put raw html code on the page. Serendipity for example has a plugin called trustxss which should do exactly that, though there are many ways to circumvent that (at least all I found should be fixed in 1.3-beta1, see advisory here: CVE-2008-0124). All fields like username, user-information etc. need to be escaped and it should be the default that users aren't allowed to post html. If a superuser enables html-posting for another user, he should be warned about the security implications.
A quite different way would be separating front- and backend on different domains. I don't know of any popular CMS currently doing that, but it would prevent a lot of vulnerabilities: The website content is, e.g., located on www.mydomain.com, while the backend is on edit.mydomain.com. It would add complexity to the application setup, especially on shared hosting environments.
Second issue is XSS/CSRF in the installer. I'm not really sure how I should classify these, as an open installer most probably has more security implications than just XSS. I recently discovered an XSS in the installer of moodle (CVE-2008-0123) which made me think about this.
I thought of a (real) scenario where I was sitting in a room with a group, discussing that we need a webpage, we would take Domain somedomain.de and install some webapp (in this case MediaWiki, but there I found no such issues) there. I suddenly started implementing that with my laptop. Other people in the room hearing the discussion could send me links to trigger some kind of XSS/CSRF there. This probably isn't a very likely scenario, but still, I'd suggest to prevent XSS/CSRF also in the installer of web applications.
openvas, the successor of nessus
Friday, February 8. 2008, 14:22
Over two years ago, it was announced that the security scanner nessus will no longer be free software starting with version 3.0. Soon after that, several forks were announced. For a long time, none of these fork-projekts produced any output.
openvas was one of that forks and from my knowledge the only one that ever produced any releases. It recently had 1.0-releases for all packages, I just added ebuilds to gentoo.
While openvas isn't perfect yet (many of the old plugins fail, because some files had to be removed due to unclear licensing), it's nice to see that we have a free, maintained security scanner again that will fill the gap left by nessus.
openvas was one of that forks and from my knowledge the only one that ever produced any releases. It recently had 1.0-releases for all packages, I just added ebuilds to gentoo.
While openvas isn't perfect yet (many of the old plugins fail, because some files had to be removed due to unclear licensing), it's nice to see that we have a free, maintained security scanner again that will fill the gap left by nessus.
How long does it take to fix a crash-bug?
Friday, January 11. 2008, 05:56
About one year ago, Sam Hocevar posted some results on tests with his fuzzing tool zzuf, which showed a large number of crashes in various applications, especially multimedia apps.
Crash bugs on invalid input very often lead to security issues, thus this should be taken seriously.
Now, I took the freedom to have a look how many of the issues found back then were fixed. I used the most current versions in gentoo linux (testing/~x86-system), which tend to be quite up-to-date. I also cross-checked the crashes for other apps, as they often use the same or similar code.
Seems only vlc devs did their homework (Sam Hocevar is part of the vlc team). Interesting enough, even firefox seems to have a gif-crasher since a year.
gstreamer crash by lol-ffplay.mpg lol-gstreamer.m2v lol-mplayer.m2v lol-mplayer.mpg lol-vlc.m2v lol-vlc.mpg
endless loop by lol-ffplay.m2v lol-xine.mpg
mplayer hang by lol-mplayer.wmv,
crash by lol-ffplay.flac lol-mplayer.aac lol-mplayer.mpg lol-mplayer.ogg lol-ogg123.flac lol-vlc.aac lol-xine.aac
xine crash by lol-mplayer.wmv lol-ffplay.m2v lol-ffplay.ogg lol-ffplay.wmv lol-gstreamer.avi lol-ogg123.flac lol-vlc.aac lol-xine.mpg
firefox crash by lol-firefox.gif
Crash bugs on invalid input very often lead to security issues, thus this should be taken seriously.
Now, I took the freedom to have a look how many of the issues found back then were fixed. I used the most current versions in gentoo linux (testing/~x86-system), which tend to be quite up-to-date. I also cross-checked the crashes for other apps, as they often use the same or similar code.
Seems only vlc devs did their homework (Sam Hocevar is part of the vlc team). Interesting enough, even firefox seems to have a gif-crasher since a year.
gstreamer crash by lol-ffplay.mpg lol-gstreamer.m2v lol-mplayer.m2v lol-mplayer.mpg lol-vlc.m2v lol-vlc.mpg
endless loop by lol-ffplay.m2v lol-xine.mpg
mplayer hang by lol-mplayer.wmv,
crash by lol-ffplay.flac lol-mplayer.aac lol-mplayer.mpg lol-mplayer.ogg lol-ogg123.flac lol-vlc.aac lol-xine.aac
xine crash by lol-mplayer.wmv lol-ffplay.m2v lol-ffplay.ogg lol-ffplay.wmv lol-gstreamer.avi lol-ogg123.flac lol-vlc.aac lol-xine.mpg
firefox crash by lol-firefox.gif
Schlangenöl
Thursday, December 20. 2007, 17:43
Ich hatte in jüngster Zeit eine Kundenanfrage, die sich mit dem Betrieb eines Flash Media Streaming Servers außeinandersetzte. Nun finde ich ein Produkt ja schon dubios, wenn ich keinen Wikipedia-Eintrag dafür finde (wobei es verziehen sei, dass das möglicherweise an der Löschwut mancher Wikipedia-Admins in den vergangenen Monaten liegt).
Aber die Produktbeschreibung (von Adobe) ist echt göttlich, deswegen möchte ich Euch das nicht vorenthalten:
Flash Media Streaming Server 3 unterstützt RTMPE, eine erweiterte Version des RTMP-Protokolls (Real Time Messaging Protocol) von Adobe. Mit verbesserter Leistung und 128-Bit-Verschlüsselung bietet das neue Protokoll effektiven Schutz für per Streaming übertragene Medieninhalte. Eine neue Verifizierungsfunktion verhindert, dass SWF-Dateien von unbefugten Anwendern wiederverwendet, geändert oder gehostet werden.
Ich glaube für sowas wurde mal der Begriff Snakeoil oder Schlangenöl erfunden.
Aber die Produktbeschreibung (von Adobe) ist echt göttlich, deswegen möchte ich Euch das nicht vorenthalten:
Flash Media Streaming Server 3 unterstützt RTMPE, eine erweiterte Version des RTMP-Protokolls (Real Time Messaging Protocol) von Adobe. Mit verbesserter Leistung und 128-Bit-Verschlüsselung bietet das neue Protokoll effektiven Schutz für per Streaming übertragene Medieninhalte. Eine neue Verifizierungsfunktion verhindert, dass SWF-Dateien von unbefugten Anwendern wiederverwendet, geändert oder gehostet werden.
Ich glaube für sowas wurde mal der Begriff Snakeoil oder Schlangenöl erfunden.
Security and »mature applications«
Saturday, December 15. 2007, 22:16
Recently I had a discussion with someone about the security of various linux distributions where he claimed Debian stable to be very secure and that they use old versions where they backport all occurances of security issues. This is a common assumption, too bad that it's wrong.
I want to document this to demonstrate the dangerousness of opinions like »stay with the old software«, »never touch a running system« and alike that are not limited but often found in the Debian community.
I had a look at the security policy on a package recently very popular for it's vast number of issues, namely php. Their last php-update on php5 was in july. They have a heavily patched version of php 5.2.0 and according to their changelog the last thing they patched was CVE-2007-1864.
Now that probably means that CVE-2007-3996, CVE-2007-3378, CVE-2007-3997, CVE-2007-4652, CVE-2007-4658, CVE-2007-4659, CVE-2007-4670, CVE-2007-4657, CVE-2007-4662, CVE-2007-3998, CVE-2007-5898, CVE-2007-5899, CVE-2007-5900 are unfixed. Oh, and before you ask: This list certainly is incomplete, it's just what I found without much hassle.
Not only looking at php5, php4 is still officially distributed by many vendors, some hosters still use it. You can't really blame them, as php.net announced it to be supported until 2007-12-31. But that's theory, in fact, nobody looks if the various recent issues also apply to php 4, most recent advisories don't mention it. Fact is, at least CVE-2007-3378, CVE-2007-3997, CVE-2007-4657, CVE-2007-3998 also apply to php 4 and are unfixed in their latest release 4.4.7 (not neccessary to mention that they're not fixed in the debian stable php4 package).
If someone prefers to stay with old software, it's up to them. But be serious. It's probably a hell-job to get all the recent security issues in an app like php backported to some ancient version. A quick check showed me that debian isn't able to do that. If you can't do that, don't claim it's in any way »supported«. Because doing that put's other people in dangerous situations.
I want to document this to demonstrate the dangerousness of opinions like »stay with the old software«, »never touch a running system« and alike that are not limited but often found in the Debian community.
I had a look at the security policy on a package recently very popular for it's vast number of issues, namely php. Their last php-update on php5 was in july. They have a heavily patched version of php 5.2.0 and according to their changelog the last thing they patched was CVE-2007-1864.
Now that probably means that CVE-2007-3996, CVE-2007-3378, CVE-2007-3997, CVE-2007-4652, CVE-2007-4658, CVE-2007-4659, CVE-2007-4670, CVE-2007-4657, CVE-2007-4662, CVE-2007-3998, CVE-2007-5898, CVE-2007-5899, CVE-2007-5900 are unfixed. Oh, and before you ask: This list certainly is incomplete, it's just what I found without much hassle.
Not only looking at php5, php4 is still officially distributed by many vendors, some hosters still use it. You can't really blame them, as php.net announced it to be supported until 2007-12-31. But that's theory, in fact, nobody looks if the various recent issues also apply to php 4, most recent advisories don't mention it. Fact is, at least CVE-2007-3378, CVE-2007-3997, CVE-2007-4657, CVE-2007-3998 also apply to php 4 and are unfixed in their latest release 4.4.7 (not neccessary to mention that they're not fixed in the debian stable php4 package).
If someone prefers to stay with old software, it's up to them. But be serious. It's probably a hell-job to get all the recent security issues in an app like php backported to some ancient version. A quick check showed me that debian isn't able to do that. If you can't do that, don't claim it's in any way »supported«. Because doing that put's other people in dangerous situations.
Some XSS issues in Serendipity found
Monday, December 10. 2007, 14:48
I recently stepped upon some XSS issues in Serendipity.
The first is in the remoterss-plugin, which can be used to display the content of an RSS feed in the sidebar of a blog. It didn't escape links, so JavaScript-Code could be injected by malicious RSS feeds. This plugin is shipped with the base version of S9Y. They've released 1.2.1 this weekend which has the fix.
If you're using the remoterss plugin, you should upgrade to 1.2.1 as soon as possible. This issue is named CVE-2007-6205.
The other one is in the external mycalendar-plugin. It also allows unescaped content inside links. This wouldn't be a real issue, as this form should only be accessible by the blog administrator. But the form had no CSRF (Cross-Site-Request-Forgery) protection, so an attacker could trigger this form and thus inject javascript on the blog-page. This has been fixed within version 0.13 of the plugin, so if you're using it, please upgrade. CVE-2007-6390 now assigned.
Beside I'd like to note that I got fast replies to my reports and the s9y devs fixed them quite quickly. Thanks for that!
The first is in the remoterss-plugin, which can be used to display the content of an RSS feed in the sidebar of a blog. It didn't escape links, so JavaScript-Code could be injected by malicious RSS feeds. This plugin is shipped with the base version of S9Y. They've released 1.2.1 this weekend which has the fix.
If you're using the remoterss plugin, you should upgrade to 1.2.1 as soon as possible. This issue is named CVE-2007-6205.
The other one is in the external mycalendar-plugin. It also allows unescaped content inside links. This wouldn't be a real issue, as this form should only be accessible by the blog administrator. But the form had no CSRF (Cross-Site-Request-Forgery) protection, so an attacker could trigger this form and thus inject javascript on the blog-page. This has been fixed within version 0.13 of the plugin, so if you're using it, please upgrade. CVE-2007-6390 now assigned.
Beside I'd like to note that I got fast replies to my reports and the s9y devs fixed them quite quickly. Thanks for that!
Webmontag Karlsruhe: Talk über Datenschutz
Tuesday, November 20. 2007, 00:36
Gestern war wieder Webmontag in Karlsruhe. Ich hielt einen Vortrag über Datenschutz und Datensparsamkeit bei Webservern, im Kontext von Wir speichern nicht und dem kürzlichen Urteil gegen das Justizministerium, welches IP-Speicherung untersagte.
Die Diskussion war lebhaft, wobei es sehr schnell in Richtung juristische und politische Fragen ging, während der Vortrag sich eher auf die Technik bezog.
Slides Datenschutz und Datensparsamkeit als OpenDocument
Desweiteren gab es einen Vortrag zu OpenSocial, Bilder vom Barcamp und der Web 2.0 Expo Berlin und Lästereien über den neuen Kalender vom Karlsruher Stadtmarketing.
Die Diskussion war lebhaft, wobei es sehr schnell in Richtung juristische und politische Fragen ging, während der Vortrag sich eher auf die Technik bezog.
Slides Datenschutz und Datensparsamkeit als OpenDocument
Desweiteren gab es einen Vortrag zu OpenSocial, Bilder vom Barcamp und der Web 2.0 Expo Berlin und Lästereien über den neuen Kalender vom Karlsruher Stadtmarketing.
Computer culture, Security, Webdesign |
Comments (0)
| Trackbacks (0)
Defined tags for this entry: apache, datenschutz, datensparsamkeit, karlsruhe, vortrag, web20, webmontag
« previous page
(Page 2 of 4, totaling 59 entries)
» next page