Check For Memory Leaks!

Last week I've lost at least three hours in understanding and fixing a small open source library that was leaking memory. The incredible thing was the amount of allocated memory (half of whom never freed). Basically, the library is a overcomplicated implementation of a binary tree in C that, for less that 1 KB of data, leaks 8 KB of RAM.

My first intention was to throw away that piece of junk code, but unfortunately I didn't have the time to rewrite it, so I started hunting. But understanding the mass of functions and when they are called was taking too long, so I decided to call my old friend Valgrind.

Valgrind is an excellent tool for detecting memory leaks. The simplest way to use it is the following:

valgrind --leak-check=yes program_to_test [parameters]

This is enough to provide you the total amount of allocated memory with a list of blocks that have not been freed (if present). And, for everyone of these, there is the full call hierarchy to let you quickly identify why it was allocated.

Of course, Valgrind can do much more than this but its usage to find memory leaks is the minimum thing that every developer must do before releasing a software. And the fact that the code is open source is not an excuse: you must ensure the quality of your program, no matter how many people will read the source code.

development, open source, Valgrind, working life Tuesday, April 07, 2015 No comments

The Day That Killed Groupon Reputation

This Thursday I was looking at the social networks in a moment of rest, when the hashtag #defendGNOME gained my attention. For the ones that are not Linux addicted, GNOME is a famous desktop environment that had several forks (XFCE, Mate, etc.) and it has been the main choice for Ubuntu for many releases.

All the messages in Twitter and Google+ (and I suppose Facebook too) linked to a communicate in the GNOME Foundation website. Below there is the relevant part of the message, followed by the request to donate.

[...] Recently Groupon announced a product with the same product name as GNOME. Groupon’s product is a tablet based point of sale “operating system for merchants to run their entire operation." The GNOME community was shocked that Groupon would use our mark for a product so closely related to the GNOME desktop and technology. It was almost inconceivable to us that Groupon, with over $2.5 billion in annual revenue, a full legal team and a huge engineering staff would not have heard of the GNOME project, found our trademark registration using a casual search, or even found our website, but we nevertheless got in touch with them and asked them to pick another name. Not only did Groupon refuse, but it has now filed even more trademark applications [...]. To use the GNOME name for a proprietary software product that is antithetical to the fundamental ideas of the GNOME community, the free software community and the GNU project is outrageous. Please help us fight this huge company as they try to trade on our goodwill and hard earned reputation. [...]

http://www.gnome.org/groupon/

In few words, last spring Groupon decided to create a tablet with a proprietary OS and name it Gnome, in spite of that name is already being used since several years from an open source project. So the Foundation started a fundraising with an associated social network campaign.

The result has been quick and massive. I just want to show you one tweet among the others, very representative of the dimension of Groupon fail:

Wow @Groupon! You are choosing to make enemies of those who RUN the internet. Good luck with that… 😳 #gnome @Kuningaskunta @nixcraft @gnome
— Toby Sanchez (@_tobyWan_) November 11, 2014

Probably someone at Groupon had understood what was going to happen and quickly tried to calm the things down with this is the communicate (the emphasis is in the original).

Groupon is a strong and consistent supporter of the open source community, and our developers are active contributors to a number of open source projects. We’ve been communicating with the Foundation for months to try to come to a mutually satisfactory resolution, including alternative branding options, and we’re happy to continue those conversations. Our relationship with the open source community is more important to us than a product name. And if we can’t come up with a mutually acceptable solution, we’ll be glad to look for another name.

UPDATE: After additional conversations with the open source community and the Gnome Foundation, we have decided to abandon our pending trademark applications for “Gnome.” We will choose a new name for our product going forward.

https://www.groupon.com/blog/cities/gnome-update

So the happy ending has come. The name GNOME is safe and it will continue to indicate only an open source software. And Groupon will remember for many years that the community is more important than lawyers and money.

Image by ilnanny licensed under CreativeCommons by-nc-nd 3.0

ethics, GNOME, Groupon, Linux, open source, social networks Thursday, November 13, 2014 No comments

ShellShock: Impact On Average People

In the previous post, I've written about the ShellShock vulnerability in a general way. Now I want to talk about how this vulnerability can impact all the average internet users.

So the question is: what can you do to protect yourself when surfing the web? The same good old things.

Check Your Router

As said in the previous post, there is a remote possibility that your router (if you have one) is vulnerable. To understand if you are at risk, the best thing to do is  is to take a look at the producer website. If you are lucky enough, a patch is already available. In any case, you should try before you trust.

Offline tests:

• https://community.qualys.com/blogs/securitylabs/2014/09/25/qualysguard-remote-detection-for-bash-shellshock
• http://pastebin.com/raw.php?i=166f8Rjx

Online tests (not recommended - it's not a good thing to let someone know that your router can be attacked):

• http://www.shellshocktest.com/
• http://shellshock.brandonpotter.com/

Use An Updated Browser

Since ShellShock vulnerability can be used to inject malicious code in trusted websites, this probably will result on several tries to take advantage of old and new known browser breaches. If you keep your browser always up to date, you'll be less vulnerable. Avoiding Internet Explorer is a good solution too.

Something should be said also for two products that usually act as plugins for the browser: Java and Flash. There are plenty of exploits based on vulnerability of these two products so it's better to disable them by default and allow their execution only if they are really needed.

Use An Updated OS

I know that you feel comfortable with Windows XP but you should know that Microsoft is not providing security patches anymore. This means that every vulnerability being discovered will never be fixed.

[If you feel comfortable with Windows Vista, please contact a doctor <grin />]

Use An Updated Antivirus

Nowadays AVs are smart enough to detect a wide range of malicious web attacks, even unknown ones with their heuristic algorithms.

There are plenty of good free and non-free antivirus out there: pick one and install it. An average AV is better than no AV.

This suggestion is basically for Windows and Adroid users but Mac addicted should worry too.

Conclusions

As you can see, all the above suggestions give you  more or less the same hint: keep everything up to date. This is because security is a process. This means that there is nothing that can be considered truly attack proof except if it is turned off and with the cable (or the battery) unplugged.

embedded, open source, security, shell Saturday, October 04, 2014 No comments

ShellShock, What I've Understood

Disclaimer: I'm not a security specialist; if you are running a webserver, please consider asking a qualified technician.

If last week you have been to Mars, maybe you haven't heard about the new security issue named ShellShock (CVE-2014-6271), claimed to be even more dangerous than HeartBleed.

In few words, it's a vulnerability in the Burn Again Shell (bash) in all Unix-derived systems (Linux, BSD and MacOS) [and maybe Windows too] that can be triggered via a remote call to a web server that uses CGIs. The following is a simple method to understand if your system is vulnerable (taken from here):

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"

env X="() { :;} ; echo busted" `which bash` -c "echo completed"

Run these two commands from a shell; if you read "busted", your system is vulnerable.

Obviously, the preferred targets for attacks based on this vulnerability are the webservers directly connected to internet. And this don't mean only those that run large companies websites, but also embedded devices, such as routers and IP cams.

Embedded Systems: Not So Bad

Due to the limited power of the hardware, embedded systems usually don't have the standard bash binary but use the shell functions provided by BusyBox that is not vulnerable.

This is true for many embedded devices but not for all; for this reason, if you own one of those,  I suggest you to verify with the producer or by yourself, if you are skilled enough.

Webservers: Pretty Bad

I'll assume that your system is correctly configured: since this vulnerability does not involve privilege escalation, all the commands being executed by the exploiter will run with the same privileges of the webserver application and its CGIs. Of course, if Apache is running with root permissions, you are in big troubles even if your system is not vulnerable, but this is a different story.

That said, this vulnerability can be tapped in five ways.

1. Making the server slow or unavailable, for example running busy loops or filling the memory with an infinite series of forks.
2. Stealing your data (restricted pages on the website and databases).
3. Deleting all data accessible from webserver and CGIs (webpages and databases): you can mitigate this risk with frequent backups.
4. Being used for a DOS attack against other sites.
5. Injecting malicious scripts or redirecting the visitors to malicious sites. This is the worst scenario: with sed or awk it is quite simple to change every HTML page (but also JavaScript files or Python CGIs) to inoculate code that can take advantage of some browser vulnerability - or simply deface your homepage.

To add some more fear, some of the above can be combined to increase the damage.

Conclusions

ShellShock is a vulnerability that should not be underestimated but probably it's not so bad as it has been reported. Many embedded systems, that are more likely to not receive an update, are not affected. And nowadays many technologies other than CGI are used.

Now, if you are asking if there is something that average people can do to mitigate the risk, you'll have to read this post for the answer.

embedded, open source, security, shell Monday, September 29, 2014 No comments

Authors In The Open Source World

Last week, Seth Godin wrote another great post. This time the argument is the difference between companies and authors. No company would endorse a competitor while writers often suggest books written by others.

The implicit message is that culture is not a product.

Image by Andrew

For FOSS developers it works almost the same. If someone is creating a good software, his project will be not only praised but also improved by other developers. And the good part is that they share their work for free.

For these reasons I think that with the following sentence, Seth is describing a situation wider than he thought.

It's not a zero-sum game. It's an infinite game, one where we each seek to help ideas spread and lives change.

open source, personal Thursday, September 04, 2014 No comments

Has Open Source Failed?

Image taken from here

This week has been pretty embarrassing for GNU/Linux estimators. According to ArsTechnica a bug has been found on the GnuTLS library. Basically the authenticity of SSL/TLS certificates was not granted (a similar issue has been found recently on Apple iOS - I mentioned it here).

This bug is present since 2005 (a century in computer science) and it seems to affect a wide range of devices - not only PCs.

During these days I've read several commentators pointing their fingers against the open source philosophy. Probably they are the same people that exult when an error is found on Wikipedia.

To those, I just want to remind that, for example, inside Windows XP Professional there are still 44 unpatched vulnerabilities and a couple of them are present since 2003 (two centuries in computer science).

What we can say is that software - every software - has bugs (by design, let me say). What makes the difference is the speed in fixing them once they have been discovered. And in this case the open source community has been very fast.

So, if you are asking me if open source is perfect, I have to say no. But, in my opinion, is better than closed source under many points of view. And bug fixing is one of them.

bugs, Linux, open source, security Saturday, March 08, 2014 No comments