All that is wrong with the world…

February 27, 2010

Is making use of unprotected Wi-Fi stealing?

Filed under: Security, Tech — Tags: , , , , , , , — allthatiswrong @ 7:18 pm

Table of Contents

Introduction
Does WEP count as unprotected?
The “unlocked door” analogy
Is it really stealing?
Whose responsibility?
There is no excuse
Legal issues
Conclusion
References

Introduction

I have seen this issue popup quite a lot and it is an interesting topic of discussion. There have been many interesting cases of people being arrested for accessing open Wi-Fi connections as legal systems adapt to the presence of this new technology. Unfortunately most of the prominent court cases have been based around prosecuting the defendant with unauthorized computer access and in some cases theft. Certainly many people seem to share the opinion that making use of a connection you did not have access to is in some way stealing, or at least morally wrong.

In this article I argue that accessing an unprotected Wi-Fi network is not stealing, nor is it in any way morally wrong. I have chosen the term unprotected Wi-Fi to remove any ambiguity, so as to refer to all Wi-Fi networks that have encryption disabled, and offer a DHCP lease and network access to any device that requests it. This is in contrast to the term open Wi-Fi, which some people take to mean Wi-Fi networks that are intended to be open for anyone to access.

Does WEP count as unprotected?

It is important to distinguish between an unsecured Wi-Fi network, and a Wi-Fi network with any form of security. Many consider a Wi-Fi network with only WEP encryption to be unsecured, however for the purposes of this article a WEP protected Wi-Fi network is considered a secure network. The reason many people consider WEP to be equivalent to an unsecured network is because it is a very old form of security, and it can be bypassed these days often in just a few minutes.

The fact that WEP is all but useless technically is irrelevant here. What is important is that the owner made an attempt to secure their network, and by doing so made it clear that the network was not open for anyone to use. This is a big difference between leaving a Wi-Fi connection unsecured, and making an attempt to secure it. An attempt to secure a wireless network however weak is still making the intention of the owner clear. This is equivalent to hanging a keep out or no trespassing sign on a private property. While it can be easily bypassed, there can be no question that doing so is going against the owners wishes.

This is in contrast to an unsecured Wi-Fi network where the intention of the owner is ambiguous, and we only have limited information to go by. With an unsecured Wi-Fi network not even the most minimal of efforts have been made to keep people out, despite it often being trivial to do so. With a device that broadcasts its presence and allows anyone to join upon request it is fair to assume you are allowed to use this network. This situation is similar to trespassing law in many countries, whereby it cannot be considered trespassing if no effort was made to warn people of the private property.

The “unlocked door” analogy

One of the most common arguments against using an unsecured Wi-Fi connection is to compare the situation to someone leaving the door to their house unlocked and arguing that this is analogous to leaving a Wi-Fi connection unsecured. Unfortunately this analogy is specious as best.

A Wireless AP broadcasts radio waves in all directions for hundreds of feet announcing its presence and in many cases supplying the authorization and information necessary to join a network. An AP is set by its owner to either allow anyone to join the network, or to only allow people with the key to join. In this way the AP is a somewhat intelligent device acting as a gatekeeper following the orders of its owner. Unlike a door which is passive and awaits interaction, an AP is an active device sending out broadcasts and responding authoritively to requests for access.

This is what prevents any comparison to an unlocked door from being accurate. When people connect to an unsecured Wi-Fi network, they are doing so because the network advertised itself as available, and when they requested to join they were granted access. This is not the case with an unlocked door which can be physically identified as belonging to a particular residence, and which generally would require other boundaries to be broken before it can be accessed.

Unlike a locked door a wireless access point has no physically distinguishing characteristics to aid in determining if the access point was intended to be private or public. Except for the fact that is generally trivial to enable security or even change the SSID to reflect the owner’s intentions. Without even the smallest effort taken to communicate that a wireless network is intended to be private it is only reasonable to assume it is intended to be public.

From summary it would appear that the wireless network had been deliberately configured to accept connections from anyone. Just because someone configures their devices so that it broadcasts and authorizes anyone who wishes to join either due to ignorance or disregard, should someone really be arrested for then joining that network?

Understandably many people see this issue as purely a moral issue, and so wish to reduce the argument to its simplest form. Simply because someone, for whatever reasons leaves something unlocked or available, that does not give an opportunist the right to take advantage of that. Unfortunately the situation with unsecured wireless APs is more complex than a simple unlocked door analogy, and reducing it to such a simple form leaves us with a useless analogy that is no longer accurate.

Is it really stealing?

Many people are quick to label using an unsecured Wi-Fi network that the owner did not want to be used, as stealing that person’s connection or service. Most of the time however this is simply inaccurate for the same reasons as downloading a song or a movie is not stealing. The core concept of stealing let alone any dictionary definition requires that the owner be deprived of their property or service in some way for some amount of time. This is rarely the case with Wi-Fi ‘theft’.

In much of the world internet access is not metered, nor is there any finite usage limit. There is no theft of service in thiese situations as the owner of the internet connection is not deprived of using his service in anyway. They may not even be aware that someone is making use of the connection.

There are of course exceptions to this. In countries where interest access is ridiculously limited such as Australia or in developing countries, or where someone takes advantage of the network and saturates the connection, then it is accurate to say that the owner is being deprived of something which is theirs, so an argument can be made that it is indeed stealing.

There is also the viewpoint that since the wireless AP is broadcasting onto your private property without needing any effort on your part it is not stealing. Similar to how accessing television or radio signals broadcast over public frequencies cannot be considered stealing, nor can accessing a publicly broadcasted Wi-Fi signal. I am not convinced this argument is similar enough to the Wi-Fi situation o have merit, however I find it irrelevant as accessing unsecured Wi-Fi cannot be said to be stealing as the deprivation criterion has not been met.

Some people also hold the view that accessing an unsecured Wi-FI for internet access without explicit permission from the owner is not just stealing from the owner, but also from the ISP who provides the internet service. This is simply incorrect. The ISP is irrelevant here unless the contract specifically disallows providing internet access through unsecured Wi-Fi. Most contracts however simply contain a clause against reselling and not against making it freely accessible have. Accessing the internet through an unsecured Wi-Fi connection is no more stealing from the ISP than watching a friends cable TV is stealing from the cable company.

For the most part however people who connect to an unsecured Wi-Fi connection are in all likelihood only going to only be visiting some simple web -pages and perhaps emailing. There will always be some people who will take unfair advantage of such a connection or use up a download quote on metered connections, but these are exceptions to the rule. Generally, making use of an unsecured Wi-Fi connection does no harm to the owner and should not be considered stealing.

Whose responsibility?

There is also the question of who should bear the responsibility when someone connects to an unsecured Wi-Fi network. Most people are quick to blame the clients along with accusations of theft, but is this really fair? As I point out a bit further down, when someone installs a wireless access point most of the time they must consciously leave security disabled, or at least be aware that they have done so.

If someone leaves their car unlocked with the keys in the ignition and it gets stolen, many places will hold the owner of the car responsible. Many regions have explicit laws against this situation which find the owner at fault. As much as taking advantage of a car with the keys left in it is wrong, we live in a world where crime is inevitable, as such people must be responsible to a reasonable degree for their possessions.

That is not a terrific example as stealing a car is indisputably morally wrong – no question about it. This is less true for connecting to an unsecured Wi-Fi however. While an analogy can be made between leaving an AP unsecured and broadcasting and leaving a car unlocked with keys inside, it is obvious that the car belongs to somebody and is not yours to take. It is rare that it is as obvious that an unsecured Wi-Fi network is not intended to be used.

In most cities there are literally hundreds of networks, some may be provided by a city or council, some may be provided by some sort of organization or business and some may be provided by people genuinely happy to share their connection. With Wi-FI being near ubiquitous how are most people to know if a network is intended to be free for use by anyone or intended to be private? The answer is they cannot, nor should they have to. The onus must be on the owner of the AP to read the manual that came with their device, or to have someone to set it up for them if they lack the knowledge to do so.

It is also important to keep in mind that many laptops and devices will connect to an unsecured wireless network by default without user intervention. Many people may not realize they are not authorized to be on an unsecured wireless network and will only note that their computer has picked up free internet. To prosecute people for using their devices as intended when enabled only due to the ignorance or laziness of an AP owner is wrong.

A more accurate analogy to stealing a car with keys in the ignition might be accessing a public website. If a family or individual decided to place some private photos on a website and only share them with friends, yet made no effort to protect them and someone stumbled across them, who is at fault? Websites are intended to be public unless locked down, so how could the person who stumbled across an apparently public website be expected to know any better?

The ignorance of the owner is not an excuse here. There is no need to know about .htaccess or such as hosting companies provide a simple interface to password protect directories and generally provide free support. Just as a person accessing a public website could not know the owner did not intend for the website to be public, most people accessing an unsecured Wi-Fi network would have no reason to assume the network was not intended to be open. In all cases the owner must bear responsibility for securing their property without exception.

There may be many reasons that people deliberately leave their wireless network unsecured, while being aware of the risks. Whether motivated by convenience, compatibility or any other reason is irrelevant. If you are aware of the risks and decide to leave your wireless network unsecured then you must accept the possibility of people connecting to and using it. Leaving your front door unlocked may be more convenient, but you could not expect any insurance payout in the event of a robbery.

There is no excuse

These days there really is very little excuse to leave a wireless network unsecured as a result of ignorance. Every router or modem in made in at least the last five years either stresses the importance of enabling security for your wireless AP, or more commonly will force you to make a decision when first setting up the device.

There is no prerequisite of technical knowledge required to enable security. Wireless AP manufacturers are well aware that most people do not have even a basic technical understanding and their devices are designed accordingly. When setting up the majority of devices, you must explicitly choose an option equivalent to “No security” which is generally advised and warned against, or choose one of the security methods and provide a password or key. Indeed, many devices these days go so far as to have a default key or passphrase as a sticker on the box allowing the devices to be secure by default and making it easy for clients to join.

Some of the most common Wireless AP’s for consumers are the NetGear WGT624, NetGear WNR350, Linksys WAG160N, Dlink DI-524 and the Belkin Wireless G router. All of these routers have been around for around 5 years or more. They all provide strong, hard to miss advice recommending against leaving security off, and all force you to explicitly disable or enable security during the quick setup.

Unfortunately the only argument I have ever encountered against this rather basic axiom was based on lies and misrepresentation. The fact of the matter is it is difficult to avoid making a choice to enable security on any router from the last 5 years. If we acknowledge that the majority of people operating an unsecured Wi-Fi network explicitly chose not to enable security, it is only reasonable to assume they have no problem with people openly using their unsecured Wi-Fi network.

In the event that someone honestly may not have any technical knowledge at all and finds it all too confusing, it is likely they will have someone qualified to set things up for them. The qualified person will either enable security for this person, or explain the choices in which case again the owner of the wireless network must make a choice to disable security.

Even if someone happened to have an exceptionally old or uncommon router that does not advise or force you to make a choice regarding security, there are still many other avenues in which users will have been informed:

  • ISPs
  • Their Operating System
  • News/Media
  • Whoever is responsible for doing computer maintenance or repair

Additionally, in the event that someone owns a very old router and had somehow managed to avoid all the above avenues which make clear the ramifications of running an open Wi-Fi, it Is likely that the router firmware will be updated at some point, then making it necessary to make a choice regarding security.

The only counterpoint I have seen to this was a rather idiotic argument trying to compare people deliberately choosing to have security disabled for whichever reason to people being taken advantage of in Nigerian mail scams. This is also the prevailing problem with the most popular view on this issue today, equating a willful ignorant owner of a wireless AP with being a hapless victim taken advantage of.

Of course there are exceptions to my argument. There may be people with very old pre-2005 routers who never needed to update the router firmware or read the manual. These people never needed to hire anyone more qualified because their setup already worked. They didn’t pay attention to warnings mention by media about leaving your Wi-Fi networks unsecured and didn’t consider warnings from the OS to be relevant.

These people are the exception to the rule and as such do not negate what should be considered the general guiding rule. If someone left their Wi-Fi unsecured it was most likely intentional regardless of the reasons for doing so. It takes a very special case to claim true ignorance and to ignore all of the various methods people are made aware of the risks of running an unsecured Wi-Fi network.

Legal issues

The legal issues of connecting to an unsecured Wi-Fi network are complex and tend to differ substantially by country or state. Unfortunately many of the most public cases from the US and UK of people accessing an unprotected Wi-Fi network have resulted in people being prosecuted for stealing or theft. This is wrong on many levels, not least because it ignores any culpability attributable to the owner

Much legislation against illegally accessing a computer or computer network makes use of the word authorization. In a purely technical context there should be no issue here, as when connecting to an unsecured Wi-Fi network you must be authorized by the AP to do so. Of course, the law is about the intent of people and not the actions of machines. Even so, should the fact that owners of Wi-Fi access points decline to explicitly protect their network not be taken as an implicit authorization?

In Australia, Canada, the UK and likely most countries it is illegal to access an unsecured Wi-Fi network without explicit permission from the owner. In contrast to common sense where you would assume an unprotected network is open, you must instead make sure you have the consent of the owner of the network you are connecting to. This creates a somewhat dangerous situation…what if a small café or business offered free Wi-Fi and decided they didn’t like a particular customer? Under these laws they could have that person prosecuted if he accessed their open Wi-Fi network, despite not having done anything wrong. Recently the UK has announced they will attempt to practically outlaw all open or unsecured Wi-Fi networks with their Digital Economy Bill, making network owners equal to ISPs as well as being responsible for all content transmitted over their network and having to keep detailed logs and access records.

In the US at least it would appear to not be a federal crime. According to Title 18 (Crimes and criminal procedure) of the United States Code, Part I (Crimes), Chapter 119 (Wire and electronic communications interception and interception of oral communications) it is not illegal to access electronic communications readily accessible to the general public. Readily accessible to the general public is defined as not being encrypted and broadcast over public frequencies. However I have not seen or heard of any case coming under federal jurisdiction with most cases being handled by state legislation instead. In Texas and Florida the situation is similar to that of Canada and Australia, where the owner bears no responsibility for operating an unsecured Wi-Fi network and anyone accessing it without permission of the owner has committed an illegal act.

The state of New York has a saner approach in that owners bear the responsibility for protecting their networks, and unauthorized access occurs only when protections are intentionally bypassed. The proposed House Bill 495 for New Hampshire was interesting, being similar to the New York legislation in which the responsibility was placed on the owner for securing their network. Unfortunately however this bill was ultimately not passed.

In Germany there does not seem to be any issue with connecting to an unsecured Wi-Fi network as it is clear that an unsecured AP is open and available for anybody to use. Instead the law seems to target the owners who fail to secure their network in that they must bear responsibility and making them liable for certain actions. Out of all of the legislation and cases I have seen Germany and New York seem to have the most practical and rational laws. The UK seems to have the absolute worst laws, with people accessing an unsecured Wi-Fi network possibly facing heavy penalties as well as making the networks owners soon to be responsible for all contents transmitted over their network. This is disappointing, although not surprising given the direction the UK has been heading in the last few years.

What about operating an unsecured Wi-Fi network for defensive reasons, similar to how Bruce Schneier advocates? Many people are of the opinion that leaving their Wi-Fi network accessible will be a valid defense in the event they are accused of some illegal act. This issue however is quite complex, and depends both on the region you are in, and if it is a civil or criminal case.

In a criminal case the prosecution has a higher burden of proof and must show you to be guilty beyond a reasonable doubt, or the equivalent in countries other than the US. In a civil trial however the plaintiff only has to prove guilt on the Preponderance of the evidence (or equivalent). The RIAA for example has successfully prosecuted many people for filesharing based on nothing more than an IP address.

With some regions considering Wi-Fi owners to be liable for what is downloaded over their connection – such as the recent case in the UK where a pub owner was fined for a movie download, having an open Wi-FI network is no defense at all. In other regions network operators are not responsible for what other people do on the network, provided there is nothing incriminating on their computer or in their residence. In such a case a person may be successful in establishing the equivalent of reasonable doubt; however this is far from a sure thing.

An interesting parallel can be drawn between cordless phones and unsecured Wi-Fi networks. When cordless phones were introduced to the market there was no security, and it was easy for anyone within distance to eavesdrop on conversations. This actually went to court in the US with the judge ruling that since the owner was broadcasting over public airwaves there could be no expectation of privacy. Ten years later the situation has been completely reversed.

Rather than making it easy for innocent people to be prosecuted with vague and ambiguous “unauthorized access” legislation as a result of the ignorance and/or laziness of wireless network owners, I would much rather see some sort of computer trespassing law, putting the onus on the network owner to inform people they are not authorized.

Prosecuting people for connecting to an unsecured Wi-Fi for doing nothing more than checking their email or the news is wrong. It sets a dangerous precedent, shifting the responsibility of properly configuring their equipment onto the user who saw a Wi-Fi network advertised as available and connected accordingly.

Conclusion

Technically there should be no problem here as it is hardware and software working exactly as it was designed to do. Legally it can depend on your country and jurisdiction. Morally there is generally no issue as it has been established that most users decide to leave such networks open. While there may be some people who take unfair advantage of an unsecured wireless network, these people are the extreme, and are distinct from simple accessing the wireless network.

As noted while there are exceptions to the rule they are irrelevant to what should be the general attitude. Just as it is reasonable in society to assume it is reasonable to open a shop during business hours if the door is open, it is reasonable to assume an unprotected Wi-FI network is free to be used. Entering a shop with an open door that was actually closed should not result in being prosecuted for trespassing, just as connecting to an unsecured wireless network should not result in prosecution for theft.

It should be noted that my argument and opinion is limited to the English speaking countries and Europe. It would also apply in countries where the same AP manufactures have market dominance similar to those of the English speaking countries such as D-Link and Linksys. If there are countries where a local or niche brand is more popular, then that brand of AP may well not offer security as an explicit configuration step or enabled by default and so would be an additional exception to my argument.

Anecdotally it seems the same people who consider accessing an unsecured Wi-Fi network to be stealing are the same people with aging moral principles who don’t think the owners of a Wi-Fi network should bear any responsibility for their actions. That people should be free to setup their wireless network and anyone accessing it without permission is in the wrong. This view is incorrect for all the reasons outlined above, and yet it is unfortunately the view of the majority.

It is also worth mentioning that many APs allow for multiple SSID’s to be setup. What this means is that a secure network with encryption can be setup, as well as a deliberately unsecured network for guests to access. It is quite probably that a signficiant portion of unsecured Wi-Fi networks are deliberate making use of this functionality.

Update 1 – April 4th 2011

A Dutch court recently ruled that deliberately hacking into a WiFi AP is not a criminal offense, as they do not consider a router to be a computer. My understanding behind the courts logic is that since the router does not store personal information it should not be classed the same as a PC. Interesting, but I don’t really see how that is relevant. By intentionally breaking into a network, you now have direct access to other PC’s, can screw with the network and do all sorts of nefarious deeds. To be clear, it is still considered a civil offense so that the owners may seek damages and I would think that if the PC’s behind the network were attacked in some fashion it would be a criminal offense. It’s an interesting take and the more I think about it, the more sense it seems to make.

References

  1. http://blogs.computerworld.com/why_its_ok_to_steal_wi_fi A blog entry by Mike Egan, advocating the view that accessing unsecured Wi-Fi is not stealing.
  2. http://www.wired.com/politics/security/commentary/securitymatters/2008/01/securitymatters_0110 – Bruce Schneier advocating leaving Wi-Fi networks open for the good of society.
  3. http://news.bbc.co.uk/2/hi/6960304.stm – A BBC commentary asking if stealing Wi-FI is wrong.
  4. http://www.pcmag.com/article2/0,2817,1565274,00.asp – John Dvorak advocating the view that the owner of a Wi-FI network should bear responsibility, not the people who access it.
  5. http://www.securityfocus.com/columnists/237 – An interesting SecurityFocus article on the subject of authorization in the context of unprotected Wi-Fi
  6. http://www.wi-fi.org/news_articles.php?f=media_news&news_id=1 A Wi-Fi Alliance survey from 2006, showing that 70% of Americans enable security on their wireless devices, and 83% consider stealing wrong.
  7. http://www.sophos.com/pressoffice/news/articles/2007/11/wi-fi.html – A sophos survey from 2007, showing 54% of people see nothing wrong with accessing unsecured Wi-FI connections. As with filesharing, when legislation makes an activity the majority of the population perform illegal, it’s time to change the law.
  8. http://www.ispreview.co.uk/story/2010/01/08/usa-home-to-more-open-wireless-wifi-broadband-hotspots-than-eu-and-uk.html – According to WeFi statistics, approximately 30% of WiFi AP’s in the world are unsecured. I wonder just how many were left unsecured intentionally?
  9. http://www.smh.com.au/nsw/revealed-keneallys-transport-blueprint-20100219-olzc.html – A newspaper hacks into a site by guessing the URL. Most people would consider the onus is on the site owner to protect their content since it is a public website. Why is this position reverse so often for Wi-Fi networks, when joining an unsecured network is significantly less effort than guessing a URL?
  10. http://www.oucs.ox.ac.uk/network/wireless/services/owl/vpn/xp_sp1/select2.png – Windows XP advising that a network is unsecured. You actually have to tick a box to acknowledge this and connect anyway.
  11. http://arstechnica.com/tech-policy/news/2007/04/child-porn-case-shows-that-an-open-wifi-network-is-no-defense.ars – An Ars Technica article about a case where having an unsecured Wi-Fi network was no defense.
  12. http://www.cbsnews.com/stories/2005/07/07/tech/main707361.shtml – Man arrested for stealing Wi-Fi in St. Petersburg Florida
  13. http://arstechnica.com/tech-policy/news/2007/05/michigan-man-arrested-for-using-cafes-free-wifi-from-his-car.ars – Man arrested for using free Wi-Fi from a café in Michigan
  14. http://www.pcworld.com/article/136326/london_man_arrested_for_stealing_wifi.html – A man arrested in London for using an unsecured Wi-Fi network.
  15. http://news.bbc.co.uk/2/hi/uk_news/england/hereford/worcs/6565079.stm – Two people cautioned for accessing unsecured Wi-Fi networks.
  16. http://torrentfreak.com/victims-of-wifi-theft-not-responsible-for-illegal-uploads-080709/ – A German court ruling Wi-Fi network operators are not responsible for what other users do on their network.
  17. http://news.zdnet.co.uk/communications/0,1000000085,39909136,00.htm?tag=mncol;txt – A contrasting case in the U.K. where a pub was fined £8000 and found responsible for downloads guests made on its Wi-Fi network.
  18. http://news.zdnet.co.uk/communications/0,1000000085,40057470,00.htm?tag=mncol;txt – The UK is planning to outlaw open/unsecured Wi-Fi networks with its Digital Economy Bill.
  19. http://caselaw.lp.findlaw.com/cgi-bin/getcase.pl?court=6th&navby=case&no=950180p – A sixth circuit court ruling on the expectation of privacy for cordless phones
  20. http://www.lawtechjournal.com/articles/2009/01_091026_nowicki.pdf – A criticism of Michigans computer crime statute
  21. http://www.mcguirewoods.com/news-resources/publications/technology_business/roaming.pdf – An Article in the CRi journal, arguing that Wi-Fi roaming should be not be illegal
  22. http://www.wired.com/gadgets/wireless/news/2003/04/58651 – A Wired article on the proposed House Bill 495
  23. http://www.justice.gov/criminal/cybercrime/wiretap2510_2522.htm – Federal wiretap law from USDOJ
  24. http://economictimes.indiatimes.com/News_by_Industry/Trai_plans_to_prevent_WiFi_abuse/articleshow/3491302.cms – WiFi networks to be required to be protected in India, to prevent terrorists making use of them.
  25. http://mashable.com/2010/02/22/stolen-wifi-confusion/ – A woman calling in to Leo Laporte who had been using an unsecured wifi for over a year without realizing. Obviously ignore all of his nonsense about it being illegal and stealing.

January 20, 2010

The insecurity of OpenBSD

Filed under: Security — Tags: , , , , , , , , , , , , , , — allthatiswrong @ 11:29 pm

Table of Contents

Introduction
Secure by default
Security practices and philosophy
No way to thoroughly lock down a system
The need for extended access controls
Extended access controls are too complex
Conclusion
References

Introduction

Firstly, I would to apologize for, and clarify the title of this article. I wanted to use a title which would hold attention and encourage discussion while remaining true to the argument I make. I certainly don’t mean to imply that OpenBSD is a horribly insecure operating system – it isn’t. I do however need to highlight that OpenBSD is quite far removed from a secure operating system, and will attempt to justify this position below.

To start, we must clarify at a bare minimum what a secure operating system can be considered to be. Generally, this would be taken to mean an operating system that was designed with security in mind, and provides various methods and tools to implement security polices and limits on the system. This definition cannot be applied to OpenBSD as OpenBSD was not designed with security in mind and provides no real way to lock down and limit a system above standard UNIX permissions, which are insufficient.

Despite this OpenBSD is widely regarded as being one of the most secure operating systems currently available. The OpenBSD approach to security is primarily focused on writing quality code, with the aim being to eliminate vulnerabilities in source code. To this end, the OpenBSD team has been quite successful, with the base system having had very few vulnerabilities in "a heck of a long time". While this approach is commendable, it is fundamentally flawed when compared to the approach taken by various extended access control frameworks.

The extended access control frameworks that I refer to are generally implementations of MAC, RBAC, TE or some combination or variation of these basic models. There are many different implementations, generally written for Linux due to its suitability as a testing platform. The most popular implementations are summarized below.

  • SELinux is based on the FLASK architecture, is developed primarily by the NSA, and ships with some Linux distributions by default, such as Debian and Fedora. SELinux implements a form of MAC known as Domain and Type Enforcement.
  • RSBAC is developed by German developer Dr. Amon Ott, and is an implementation of the GFAC architecture. RSBAC provides many models to choose from such as MAC, RBAC and an extensive ACL model. RSBAC ships with the Hardened Gentoo distribution.
  • GRSecurity is not primarily an access control framework, but a collection of security enhancements to the Linux kernel, such as JAIL support, PID randomization and similar things, as well as having an ACL and RBAC implementation.
  • AppArmor is a simple yet powerful MAC implementation, which relies on pathnames to enforce policies. Relying on pathnames is a weaker approach than that used by the above frameworks; however this is considered acceptable because it is easier to use. AppArmor ships with and is enabled is versions of Ubuntu and OpenSUSE.

There are other simpler implementations such as SMACK and Tomoyo which are officially in the Linux kernel, as well as implementations for other platforms such as TrustedBSD and Trusted Solaris. Each of these access control frameworks provide for additional security to be setup when compared to what can be done with OpenBSD by default.

Secure by default

OpenBSD is widely touted as being ‘secure by default’, something often mentioned by OpenBSD advocates as an example of the security focused approach the OpenBSD project takes. Secure by default refers to the fact that the base system has been audited and considered to be free of vulnerabilities, and that only the minimal services are running by default. This approach has worked well; indeed, leading to ‘Only two remote holes in the default install, in a heck of a long time!’. This is a common sense approach, and a secure default configuration should be expected of all operating systems upon an initial install.

An argument often made by proponents of OpenBSD is the extensive code auditing performed on the base system to make sure no vulnerabilities are present. The goal is to produce quality code as most vulnerabilities are caused by errors in the source code. This a noble approach, and it has worked well for the OpenBSD project, with the base system having considerably less vulnerabilities than many other operating systems.

Used as an indicator to gauge the security of OpenBSD however, it is worthless. The reason being is that as soon as a service is enabled or software from the ports tree installed, it is no longer the default install and the possibility of introduced vulnerabilities is equal to any other platform. Much like software certified against the common criteria, as soon as an external variable is introduced the certification, or in this case the claim can no longer be considered relevant.

It is important to note also that only the base system is audited. The OpenBSD ports tree is not audited, and much of the software available in the ports tree is several releases behind current versions, meaning that there is a strong possibility that software will be obtained from outside of the ports tree. Given that a default install of OpenBSD has all network services are disabled by default, it is very likely that software will be installed or a service enabled if the server is going to be used to actually provide any kind of service.

Since the majority of attacks are not against the base system but against software operating at a higher level actively listening over the network, it is likely that if an OpenBSD machine were attacked, it would be through such software. This is where OpenBSD falls down, as it provides no means to protect from damage in the event of a successful attack.

Providing a default secure configuration is an important practice, and one that is employed by the majority of operating systems these days. OpenBSD followed this practice in the early part of the last decade when most other operating systems did not bother, and for that the OpenBSD team should be praised. While it is a good practice it is specious at best to take this as a measure of the actual security OpenBSD provides.

It should also be noted that the OpenBSD team uses a different definition of security vulnerability, limited to vulnerabilities that are allow for remote arbitrary code to execute. While most people may consider a DOS attack or local privilege escalation problems to be vulnerabilities, the OpenBSD team disagrees. If we use a more generally accepted definition of security vulnerability, OpenBSD suddenly has a far greater number than two remote holes in the default install a heck of a long time.

Security practices and philosophy

The OpenBSD team seems very reluctant to actually admit security problems and work towards fixing them. One such example is this CoreSecurity advisory from 2007. Instead of working and testing to see the extent of the damage that could be caused by a particular vulnerability, they prefer to dismiss and assume arbitrary code execution is impossible until pushed by Core releasing proof of concept code to show otherwise. This is similar to behavior observed by many corporations. Unfortunately this seems to be typical behavior rather than an exception going by the various mailing list threads when a vulnerability is reported.

OpenBSD was never designed with security in mind. OpenBSD was started when Theo de Raadt left the NetBSD project, with the goal of providing complete access to the source repositories. The focus on security came at a later stage, along with the “secure by default” slogan. As noted above, a secure operating system is not synonymous with a lack of vulnerabilities, and certainly not with a lack of vulnerabilities limited to the base install. This should be contrasted with the various extended access control frameworks, which despite being patches to an existing project, were designed from the ground up with a focus on security.

OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions. OpenBSD is often credited with pioneering many advances in security when this is not the case. OpenBSD tends to add protections much later, and only when absolutely necessary as they continue to erroneously believe that eliminating vulnerabilities in the base system is sufficient.

It is also odd that for a project that claims to be focused on security, sendmail is still their MTA of choice and BIND is still their DNS server of choice. Sendmail and BIND are old, and they both have atrocious security records. To look through OpenBSD’s security history, many of the vulnerabilities can be attributed to BIND or Sendmail. Why would anyone choose these programs for a security focused operating system, when far more secure alternatives designed from the ground up to be secure are available? Examples might include Exim or Postfix and MaraDNS or NSD.

It is interesting to compare OpenBSD to its cousin, FreeBSD. While FreeBSD does not claim to have a focus on security, it is in fact a far more secure operating system than OpenBSD due to its implementation of the TrustedBSD projects work. FreeBSD implements proper access control lists event auditing, extended file system attributes, fine-grained capabilities and mandatory access controls which allow for a system to be completely locked down and access controlled as necessary to protect against users or break in attempts.

Despite the TrustedBSD codebase being open and available for OpenBSD to implement or improve, they reject it simply because they consider it to be too complex and unnecessary. Even if the OpenBSD team did not want to implement extended access controls they could implement proper auditing through the OpenBSD project, which they still reject as unnecessary.
It is no wonder then that when governments or organizations look for a secure operating system, they look to systems that have proper access control lists and auditing, something OpenBSD is not concerned about. A good example of this is China choosing FreeBSD as the base of their secure operating system, as OpenBSD was considered insufficient to meet the criteria.

The library calls strlcpy and strlcat should also be mentioned here. These library calls were developed by Todd Miller and Theo de Raadt as a way to eliminate buffer overflows by ensuring strings are always null terminated. However this approach is controversial, and can actually result in further problems and security vulnerabilities than they solve. While they may have their place, they should certainly not be relied on, and doing so shows a poor understanding of computer security.

No way to thoroughly lock down a system

This is the main problem with OpenBSD, and what prevents it from being able to be considered a secure system. No matter how quality the codebase or how free of vulnerabilities, there is no sufficient way to restrict access other than with standard UNIX permissions. OpenBSD team leader Theo de Raadt has openly stated that he is against anything more powerful such as MAC being implemented which is a shame. There is no good reason to avoid implementing extended access controls when the greater security and control they provide is irrefutable.

OpenBSD does offer some basic protections to protect a running system, namely the chroot functionality, chflags and securelevels. The chroot implementation is a secure version much improved over the standard UNIX chroot, but still far lacking when compared to a proper jail implementation such as that provided by FreeBSD. The consensus among OpenBSD developers and community is that you can achieve the same result using chroot and systrace. Which means they rely on a third party tool to implement a secure design that is present by default in FreeBSD, NetBSD and numerous other unices.

Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc. These protections do absolutely nothing to stop information leakage. Making files immutable or appendable only is a poor option when contrasted with the ability to prevent reading and writing/appending to only specific users or processes.

The OpenBSD project and community had access to a tool for policy enforcement named systrace. Systrace is a third party tool developed by Niels Provos, and has never been embraced by the OpenBSD team. Systrace lacks the versatility of a proper MAC implementation, and had similar weaknesses to AppArmor since it relies on pathnames for enforcement. Systrace is a form of system call interposition, which has been shown to be insecure.

The only software even close to a MAC implementation is rejected by the OpenBSD team, and is insecure. Despite this, systrace is still maintained and offered/recommended by the community as the preferred way to sandbox and restrict applications. Given this obvious deficit, it would seem even more prudent for OpenBSD to make use of the TrustedBSD project.

This is the main reason why OpenBSD is unable to offer a secure environment in the event an attacker is successful. Instead of implementing a form of extended access controls and ensuring the system is secure even in the event of a successful attack, they prefer to remove as many vulnerabilities as possible. This approach is naïve at best and arrogant at worst.

The need for extended access controls

The main argument against OpenBSD is that it provides very limited access controls. OpenBSD attempts to remove the source of vulnerabilities by producing quality code, and has such faith in this approach that very little is provided to deal with a situation when a machine is exploited, and root access obtained. Perhaps inevitably. It is this lack of access controls and protection mechanisms that prevent OpenBSD from being the secure system it is often credited as being.

It is also the reason the aforementioned frameworks such as SELinux and RSBAC have an inherent security advantage over any OpenBSD machine. Due to the use of some sort of MAC, RBAC, TE or other advanced access control used by these frameworks, a level of control is possible above that in traditional DAC systems. With a traditional DAC system, the user has complete ownership over their files and processes, and the ability to change permissions at their discretion. This leads to many security concerns, and is the reason most attacks can be successful at all.

When a computer is hacked regardless of if it is due to a drive by download targeting an insecure browser on a user’s computer or a targeted attack exploiting a server process, the malicious process or user will inherit the access of the browser or process that was attacked. The prevalence of the DAC architecture throughout most operating systems is still the primary cause of many security issues today. With many server processes still running as a privileged user this is a large concern.

It is also something that is hard to fix without changing to a different design paradigm. Many of the technologies that were developed to help prevent attacks such as privilege separation; executable space protection and process ID randomization help, but are not sufficient for a majority of cases. This is why the need for an extended access control framework is present. With the use of something like SELinux or RSBAC, the significance of individual user accounts or processes as an attack vector is decreased.

With these systems every single aspect of your system can be controlled to a fine grained level. Every file, directory, device, process, user, network connection etc can be controlled independently allowing for extremely fine grained policies to be defined. This is something that simply is not possible with current DAC systems which include OpenBSD .

As an example of what is possible with extended access controls, it a web server process running as root could be set to only have append access(as opposed to general write access available in a DAC system) to specific files in a specific directory, and to only have read access to specific files in a specific directory. If some files need to execute, then that file itself (or the interpreter if a script) can be restricted in a similar way. This alone would prevent web site defacement and arbitrary code execution in a great many cases.

On present systems using DAC if a targeted attack is successful and access to the root account is gained, there is nothing the attacker cannot do. Run their own malicious executables, alter files etc. This is why OpenBSD is necessarily less secure than any system making use of advanced access control frameworks, and also why OpenBSD is not a secure system. While OpenBSD has many innovative technologies that make it harder for an attacker to gain access, it does not provide any way to sufficiently protect a system from an attacker who has gained access.

It is possible for example to restrict something like perl or python with extended access controls. On OpenBSD if a user or an attacker has access to perl or python, then they can run whichever scripts they like. With extended access controls, it is possible to restrict only certain scripts to have access to an interpreter (and additionally make those scripts immutable), and prevent the interpreter from running at all unless called by those specific scripts. There is no equivalent fine grained granularity on OpenBSD.

Another way in which extended access controls can help is to protect against users. Even on a desktop system there is a significant security advantage. At the moment most malware requires or tries to obtain root privileges to do damage or propagate. What most people don’t realize is that even malware running as a normal user can do significant damage as it has complete access to a users files under the current DAC model. With some form of MAC, if a user decided to demonstrate the dancing pigs problem and run an untrusted piece of malware, it could be restricted from having any access to a users files or being able to make network connections.

Even windows implements a form of MAC – Mandatory Integrity Controls. While not terribly powerful, and not used for much at the moment, it still provides increased protection and allows for more security than an OpenBSD box can provide. If even Microsoft can understand the need and significance of these technologies after their track record, why is OpenBSD the only project still vehemently rejecting this technology?

Extended access controls are too complex

Some people are of the view that extended access controls are simply added complexity, which increases the scope for vulnerabilities without providing any meaningful additional security. This position makes little sense. While it is true that adding extended access controls increases complexity, the meaningful increase in security cannot be denied. There are plenty of examples of exploits being contained due to such technology…exploits that would have allowed full access to the system if OpenBSD had been the targeted platform.

It has also been said such systems only serve to shift the attack point. Instead of attacking a particular piece of software, they simply have to attack the access control framework itself. This is simply a myth. While the frameworks themselves can be attacked and even possibly exploited, the increase in security far outweighs any risk. The extended access control framework can be extensively audited and made secure while allowing policies to be enforced. Having one relatively small section of code that is easily maintained and audited and responsible for maintaining security is not a decrease in security, but an increase.

Ideally, a proper extended access control framework would also be formally verified, as I believe is the case with SELinux and RSBAC, based on the FLASK and GFAC architectures respectively. This basically means that these systems have been mathematically proven to meet all of their specifications, making it extremely unlikely that it will be possible for the systems to fail in an unexpected way and be vulnerable to attack.

In almost 10 years, there have been no vulnerabilities reported for these major systems that allowed the framework to be bypassed. The times when there has been a problem, it has been due to poor policy. The example everybody likes to mention is the cheddar bay exploit that Brad Spender(author of GRSecurity) made public in July 2007. It’s true that this exploit allowed for disabling SELinux, but this was due to a stupid policy that allowed 0 to be mmaped for the purposes of allowing WINE to work. Only the RHEL derived distributions were affected. This is not a valid example of the framework being vulnerable, and it certainly does nothing to discredit the technology as a whole.

Due to limitations of certain hardware platforms, it is possible that with the right kernel level vulnerability, an extended access control framework could be subverted. These cases however are quite rare, and with the use of technologies like PaX they become even more unlikely to succeed. In fact, as of writing this article, I am not aware of example of an extended access control being able to be successfully subverted to the contrary. There are however, examples of extended access controls successfully protecting against certain kernel vulnerabilities such as SELinux preventing a /proc vulnerability that could lead to local root.

Some of these frameworks have been criticized for being too complex, in particular SELinux. While I don’t think this is entirely justified, as the SELinux team has made great progress with making this easier with tools such as setroubleshoot and learning mode, I can understand it may be a valid concern. Even so it only applies to a specific implementation. RSBAC, which is just as powerful as SELinux has far clearer error messages and is much easier to craft a policy for. Other implementations such as that of GRSecurity are far simpler yet again. The point here is that the technology is powerful and should be embraced as the added security advantaged is undeniable.

If complexity and user unfriendliness was the main concern the OpenBSD team had then they could still embrace the idea while making the implementation simple to use and understand Instead, they flat-out reject the idea, believing antiquated Unix permissions are more than enough. Unfortunate in this day and age this is no longer the case. Security should not be grafted on, it should be integrated into the main development process. This does not mean patching in protections for specific attacks along the way which is the approach favored by the OpenBSD team. The OpenBSD approach has resulted in a very impressive and stable fortress built upon sand.

Conclusion

While the implementation of various policy frameworks will mature and grow as needed, OpenBSD will remain stale. With a refusal to implement options for properly restricting users or a system in the event an attacker does gain access, the OpenBSD system will be considered a less reliable and trustworthy platform for use as a server or user operating system.

Extended access control frameworks should not be considered a perfect solution, or the be all and end all of security. There are still many situations where they are insufficient such as large applications that necessarily require wide ranging access to properly function. Even so, the level of control these frameworks provide are the best tools we have to secure systems as best we can.

It is interesting to note that even with Linux not really caring about security and having a non disclosure policy, things still end up being more secure than OpenBSD because of the presence of extended access controls. Being able to restrict access in such a powerful way which reinforces that simply trying to eliminate all bugs at the code level while noble, is an inferior approach.

As much as I am disappointed with the fix silently without disclosure approach to security the Linux kernel project has taken since Greg K-H took over, and having to rely on sites like xorl.wordpress.com to learn about security problems that were fixed, Linux is the only real project making progress with testing and improving extended access control frameworks. With continued development and support the implementations will become easier to use and the problems eradicated until such technology is common, as it should be.

OpenBSD cannot be considered a secure system until it makes some effort towards facilitating locking down a system with more than the standard UNIX permissions model which has been shown to be insufficient, and stop discounting the possibility that a system will be secure because all bugs have been removed. While well intentioned and accurate to a small extent, it is ultimately meaningless if even just one vulnerability is present.The OpenBSD team consists of highly skilled programmers who have an interest in security and have shown excellent skill at auditing code and identifying and fixing vulnerabilities in software. Unfortunately, they have shown no interest in extending OpenBSD to implement extended access controls as almost all other operating systems have done, leaving their system inherently more vulnerable in the event of a successful intrusion. The OpenBSD serve a useful role in the community, similar to dedicate security analysts or advisors, and for this they should be celebrated.

Note: I am aware that many people use OpenBSD for nothing more than a router, and for this it indeed ideal. For the use of a router, extended access controls would not provide much benefit. I wrote this argument however because many people seem convinced that OpenBSD has suerior security in all instances and including as a network server or user operating system. I became tired of reading these comments and people simply dismissing extended access controls as too complex and not providing any real security.

References

 

  1. SELinux – http://www.nsa.gov/selinux
  2. RSBAC –http://www.rsbac.org
  3. GRSecurity – http://www.grsecurity.net
  4. AppArmor – http://developer.novell.com/wiki/index.php/Apparmor_FAQ
  5. The TrustedBSD Project – http://www.trustedbsd.org
  6. Core Security OpenBSD Advisory – http://www.coresecurity.com/content/open-bsd-advisorie
  7. Marc Espie talking about security complexity and calling MAC security theater- http://thread.gmane.org/gmane.os.openbsd.misc/129217/focus=129371
  8. Theo de Raadt stating that MAC should not be included in OpenBSD – http://www.eweek.com/index2.php?option=content&task=view&id=30680&pop=1&hide_ads=1&page=0&hide_js=1
  9. An older similar argument on the OpenBSD misc mailing list – http://kerneltrap.org/OpenBSD/SELinux_vs_OpenBSDs_Default_Security
  10. A simple argument now out of date, that makes a similar argument without going into detail – http://www.seifried.org/security/os/20011107-openbsd-linux.html
  11. Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools – http://www.stanford.edu/~talg/papers/traps/abstract.html
  12. Exploiting Concurrency Vulnerabilities in System Call Wrappers – http://www.watson.org/~robert/2007woot/20070806-woot-concurrency.pdf
  13. Bob Beck talking about systrace – http://thread.gmane.org/gmane.os.openbsd.misc/160797
  14. China chooses FreeBSD as basis for secure OS – http://blogs.techrepublic.com.com/security/?p=1682
  15. An example of SELinux preventing an exploit on RHEL 5 – https://rhn.redhat.com/errata/RHSA-2007-0960.html
  16. Dan Walsh talking about SELinux successfully mitigating vulnerabilities – http://danwalsh.livejournal.com/10131.html
  17. The start of the thread where Brad Spender’s Cheddar Bay exploit is introduced and discussed – http://thread.gmane.org/gmane.comp.security.dailydave/3905
  18. Details on the SELinux policy that allowed for the Cheddar Bay exploit – http://eparis.livejournal.com/606.html
  19. SELinux preventing a kernel vulnerability from succeeding – http://lwn.net/Articles/191954/
  20. A second example of a vulnerability that SELinux prevented, due to the users not having the required socket access- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0127
  21. A Phrack article detailing the ways current security frameworks can be exploited, and how to prevent against this – http://www.phrack.com/issues.html?issue=66&id=15
  22. A primer on OpenVMS security, a highly secure OS designed with security in mind at every level – http://www.blacksheepnetworks.com/security/resources/openvms/
  23. Presentation introducing Strlcpy and strlcat – http://www.usenix.org/events/usenix99/millert.html
  24. Start of a mailing list thread where strlcpy and strlcat are discussed and criticized – http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html

Update 1 – January 23rd 2010

I have updated the article to talk about the benefit of formal verification, and address the possibility of an EACL framework being bypassed with a kernel vulnerability.

Update 1 – April 23rd 2010

I have updated the article to reflect the correct status of the Openwall project (i.e. not abandoned), thanks to a comment by Vincent.

December 2, 2009

Keyloggers and virtual keyboards/keypads are not secure

Filed under: Security, Tech — Tags: , , , , , , — allthatiswrong @ 2:20 pm

There seems to be a common misconception that online keyboards or keypads are a useful tool in defeating keyloggers. This is only true in the case where the online keyboard is randomized or a one time password is used, which unfortunately is the exception rather than the rule. I am not aware of other people discussing this, so here goes.

Most modern software keyloggers will not only records keystrokes, but will also records the mouse coordinates each time a mouse is clicked. This is exactly why an online keyboard does nothing to negate a keylogger unless it is randomized. If I see a mouseclick at x60,y60, and subsequent mouseclicks at x48,y60 and x52, y60, then I can likely workout which keys were clicked.

The keylogger will record the site that was visited, and since the authentication page is necessarily open to anybody it allows for an attacker to workout the distance between virtual keys and the starting location of the virtual keyboard. Those mouse coordinates above can now be translated to mean that the ‘u’ key was clicked first, followed by the ‘q’ and ‘e’ keys.

Some people believe that using the windows or another virtual keyboard program is secure and will protect against keyloggers. If anything, this is worse, as the attacker does not even have to use the mouse coordinates to work out which keys were pressed. Virtual keyboard programs tend to send the same WM_KEYUP and WM_KEYDOWN events when a key is clicked, which sends the same signals as if a hardware key is pressed.

At present, relying on virtual keyboards or keypads for an extra layer of security is useless, unless they are randomized. The only way to be sure is to ensure your system is clean, by following good practices or perhaps using a virtual machine if you wish to be extra cautious.

Unfortunately most banks or secure services can’t be bothered to implement a proper system. Several of the largest banks through Australia, the USA and Europe that I have experience only have a simple text password field. This is less secure since it is directly vulnerable to keyloggers. The banks that do tend to have some sort of online keypad tend not have it randomized in any way, making it vulnerable to the attack described above. This is worse than a simple text field due to instilling a false sense of security. It is only a few banks, generally the smaller ones that actually implemented a one time password or randomized keypad.

I’m not sure why the sites trying to make a secure authentication system are not aware of this, or perhaps they simply don’t care. Perhaps like so many others, they feel that giving an illusion of security is sufficient. Customers are already protected from fraud by most laws, so it would seem the incentive to provide to increase security would favour the banks rather than customers. Which means that apparently they are not being hurt enough by fraud(despite it being one of the largest growing attacks against bank customers), which is interesting.

The Silver is the New Black Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 72 other followers