Category Archives: Security

cURL and libcurl, Network, Open Source, Security

public suffixes list

I noticed the new site publicsuffix.org that has been setup by the mozilla organization in an attempt to list public suffixes for all TLDs in the world, to basically know how to prevent sites from setting cookies that would span over just about all sites under that “public suffix”.

While I can see what drives this effort and since we have the same underlying problem in curl as well, I have sympathy for the effort. Still, I dread “having to” import and support this entire list in curl only to be able to better work like the browsers in the cookie department. Also, it feels like a cat and mouse race where the list may never be complete anyway. It is doomed to lack entries, or in the worst case list “public suffixes” that aren’t any such public suffixes anymore and thus it’ll prevent sites using that suffix to properly use cookies…

There’s no word on the site if IE or Opera etc are going to join this effort.

Update: there are several people expressing doubts about the virtues of this idea. Like Patrik Fältström on DNSOP.

Development, Open Source, Security

Coverity’s open source bug report

The great guys at scan.coverity.com published their Open Source Report 2008 in which they detail findings about source code they’ve monitored and how quality and bug density etc have changed over time since they started scanning over 250 popular open source projects. curl is one of the projects included.

Some highlights from the report:

  • curl is mentioned as one of the (few) projects that fixed all defects identified by coverity
  • from their start, the average defect frequency has gone down from one defect per 3333 lines of code to one defect per 4000 lines
  • they find no support to backup the old belief that there’s a correlation between function length and bug count
  • the average function length is 66 lines

And the top-5 most frequently detected defects are:

  1. NULL Pointer Dereference 28%
  2. Resource Leak 26%
  3. Unintentional Ignored Expressions 10%
  4. Use Before Test (NULL) 8%
  5. Buffer Overrun (statically allocated) 6%

For all details and more fun reading, see the full Open Source Report 2008 (1MB pdf)

Security

Taking down P2P botnets

Five german/french researchers wrote up this very interesting doc (9 page PDF!) called “Measurements and Mitigation of Peer-to-Peer-based Botnets: A Case Study on StormWorm” about one of the biggest and most persistent botnets out in the wild: Storm. It is used for spam and DDOS attacks, has up to 40,000 daily peers and the country hosting the largest amount of bots is the USA.

Anyway, their story on how it works, how they work on infecting new clients, how the researchers worked to infect it and disrupt the botnet communication is a good read.

Security

Bad guys reveal other bad guys

In Sweden we currently have an interesting situation where a hacking group called “Hackare utan gränser” (should probably be “Hackers Without Borders” if translated) hacked one of those auction sites where you make the lowest unique bid to win. The site in question is called bideazy and according to the hacker group’s announcement (forum posting and following discussion entirely in Swedish) their database is full of evidence of the bidding not having been done correctly and it seems to show that the site and company owner has won a large amount of all “auctions”.

And they also made most of that data publicly available.

This brings many questions in my brain, including:

First of course the evident discussion if one crime (the hacking) can be justified to reveal another (the scam), but what I think is more important: isn’t auction sites and especially the lowest-bid kinds more or less designed to open up for the sites to easily scam the users? It is very very hard for someone on the outside of it all to see if things are done the right way and that all rules are followed. Heck, even a little tweak here and there would make a huge impact for the site but won’t be seen by the public.

I also find it a bit funny that in this case is they seem to have stored the scam data neat and properly in their data base which the hackers found, and I really can’t figure out why. If they wanted a database to show as a front end if someone would ask and blame them for cheating, then this wouldn’t be the one. And since they really seem to be cheaters, why would they need to store and keep track of all the cheats in a huge database?