Posts by pmeunier
Drone “Flaw” Known Since 1990s Was a Vulnerability
"The U.S. government has known about the flaw since the U.S. campaign in Bosnia in the 1990s, current and former officials said. But the Pentagon assumed local adversaries wouldn't know how to exploit it, the officials said."
Call it what it is: it's a vulnerability that was misclassified (some might argue that it's an exposure, but there is clearly a violation of implicit confidentiality policies). This fiasco is the result of the thinking that there is no vulnerability if there is no threat agent with the capability to exploit a flaw. I argued against Spaf regarding this thinking previously; it is also widespread in the military and industry. I say that people using this operational definition are taking a huge risk if there's a chance that they misunderstood either the flaw, the capabilities of threat agents, present or future, or if their own software is ever updated. I believe that for software that is this important, an academic definition of vulnerability should be used: if it is possible that a flaw could conceptually be exploited, it's not just a flaw, it's a vulnerability, regardless of the (assumed) capabilities of the current threat agents. I maintain that (assuming he exists for the sake of this analogy) Superman is vulnerable to kryptonite, regardless of an (assumed) absence of kryptonite on earth.
The problem is that it is logically impossible to prove a negative, e.g., that there is no kryptonite (or that there is no God, etc...). Likewise, it is logically impossible to prove that there does not exist a threat agent with the capabilities to exploit a given flaw in your software. The counter-argument is then that the delivery of the software becomes impractical, as the costs and time required escalate to remove risks that are extremely unlikely. However, this argument is mostly security by obscurity: if you know that something might be exploitable, and you don't fix it because you think no adversary will have the capability to exploit it, in reality, you're hoping that they won't find or be told how (for the sake of this argument, I'm ignoring brute force computational capabilities). In addition, exploitability is a thorny problem. It is very difficult to be certain that a flaw in a complex system is not exploitable. Moreover, it may not be exploitable now, but may become so when a software update is performed! I wrote about this in "Classes of vulnerabilities and attacks". In it, I discussed the concept of latent, potential or exploitable vulnerabilities. This is important enough to quote:
"A latent vulnerability consists of vulnerable code that is present in a software unit and would usually result in an exploitable vulnerability if the unit was re-used in another software artifact. However, it is not currently exploitable due to the circumstances of the unit’s use in the software artifact; that is, it is a vulnerability for which there are no known exploit paths. A latent vulnerability can be exposed by adding features or during the maintenance in other units of code, or at any time by the discovery of an exploit path. Coders sometimes attempt to block exploit paths instead of fixing the core vulnerability, and in this manner only downgrade the vulnerability to latent status. This is why the same vulnerability may be found several times in a product or still be present after a patch that supposedly fixed it.
A potential vulnerability is caused by a bad programming practice recognized to lead to the creation of vulnerabilities; however the specifics of its use do not constitute a (full) vulnerability. A potential vulnerability can become exploitable only if changes are made to the unit containing it. It is not affected by changes made in other units of code. For example, a (potential) vulnerability could be contained in the private method of an object. It is not exploitable because all the object’s public methods call it safely. As long as the object’s code is not changed, this vulnerability will remain a potential vulnerability only.
Vendors often claim that vulnerabilities discovered by researchers are not exploitable in normal use. However, they are often proved wrong by proof of concept exploits and automated attack scripts. Exploits can be difficult and expensive to create, even if they are only proof-of-concept exploits. Claiming unexploitability can sometimes be a way for vendors to minimize bad press coverage, delay fixing vulnerabilities and at the same time discredit and discourage vulnerability reports. "
Discounting or underestimating the capabilities, current and future, of threat agents is similar to the claims from vendors that a vulnerability is not really exploitable. We know that this has been proven wrong ad nauseam. Add configuration problems to the use of the "operational definition" of a vulnerability in the military and their contractors, and you get an endemic potential for military catastrophies.
The problem is that it is logically impossible to prove a negative, e.g., that there is no kryptonite (or that there is no God, etc...). Likewise, it is logically impossible to prove that there does not exist a threat agent with the capabilities to exploit a given flaw in your software. The counter-argument is then that the delivery of the software becomes impractical, as the costs and time required escalate to remove risks that are extremely unlikely. However, this argument is mostly security by obscurity: if you know that something might be exploitable, and you don't fix it because you think no adversary will have the capability to exploit it, in reality, you're hoping that they won't find or be told how (for the sake of this argument, I'm ignoring brute force computational capabilities). In addition, exploitability is a thorny problem. It is very difficult to be certain that a flaw in a complex system is not exploitable. Moreover, it may not be exploitable now, but may become so when a software update is performed! I wrote about this in "Classes of vulnerabilities and attacks". In it, I discussed the concept of latent, potential or exploitable vulnerabilities. This is important enough to quote:
"A latent vulnerability consists of vulnerable code that is present in a software unit and would usually result in an exploitable vulnerability if the unit was re-used in another software artifact. However, it is not currently exploitable due to the circumstances of the unit’s use in the software artifact; that is, it is a vulnerability for which there are no known exploit paths. A latent vulnerability can be exposed by adding features or during the maintenance in other units of code, or at any time by the discovery of an exploit path. Coders sometimes attempt to block exploit paths instead of fixing the core vulnerability, and in this manner only downgrade the vulnerability to latent status. This is why the same vulnerability may be found several times in a product or still be present after a patch that supposedly fixed it.
A potential vulnerability is caused by a bad programming practice recognized to lead to the creation of vulnerabilities; however the specifics of its use do not constitute a (full) vulnerability. A potential vulnerability can become exploitable only if changes are made to the unit containing it. It is not affected by changes made in other units of code. For example, a (potential) vulnerability could be contained in the private method of an object. It is not exploitable because all the object’s public methods call it safely. As long as the object’s code is not changed, this vulnerability will remain a potential vulnerability only.
Vendors often claim that vulnerabilities discovered by researchers are not exploitable in normal use. However, they are often proved wrong by proof of concept exploits and automated attack scripts. Exploits can be difficult and expensive to create, even if they are only proof-of-concept exploits. Claiming unexploitability can sometimes be a way for vendors to minimize bad press coverage, delay fixing vulnerabilities and at the same time discredit and discourage vulnerability reports. "
Discounting or underestimating the capabilities, current and future, of threat agents is similar to the claims from vendors that a vulnerability is not really exploitable. We know that this has been proven wrong ad nauseam. Add configuration problems to the use of the "operational definition" of a vulnerability in the military and their contractors, and you get an endemic potential for military catastrophies.
Talking to the Police All the Time
I started writing this entry while thinking about the "if you have nothing to hide, then you have nothing to fear" fallacy. What do you say to someone who says that they have nothing to hide, or that some information about them is worthless anyway, so they don't care about some violation of their privacy? What do you say to a police officer who says that if you have nothing to hide then you have nothing to fear by answering questions? It implies that if you refuse to answer then you're probably "not innocent". That "pleading the 5th" is now used as a joke to admit guilt in light banter, is a sign of how pervasive the fallacy has become. It's followed closely with "where there's smoke there's probably fire" when discussing someone's arrest, trial, or refusal to answer questions. However, in the field of information security, it is an everyday occurrence to encounter people who don't realize the risks to which they are exposed. So why is this fallacy so irritating?
Those kind of statements expose naïveté or, if intended as a manipulative statement, perversity. It takes a long time to explain the risks and convince others that they are real, and that they are really exposed to them, and what the consequences might be. Even if you could somehow manage to explain it convincingly on the spot, before you're done, chances are that you'll be dismissed as a "privacy nut". In addition, you rarely have that kind of time to make a point in a normal discussion. So, that fallacy is often a successful gambit simply because it discourages someone from trying to explain why it's so silly.
You may buy some time by mentioning anecdotes such as the man falsely accused of arson because by coincidence, he bought certain things in a store at a certain time (betrayed by his grocery loyalty card) [1]. Or, there's the Indiana woman who bought for her sick family just a little too much medication containing pseudoephedrine, an ingredient used in the manufacture of crystal meth [2]. Possibilities for the misinterpretation of data or the inappropriate enforcement of bad laws are multiplied by the ways in which it can be obtained. Police can stick a GPS-tracking device on anyone they want without getting a search warrant [3] or routinely use your own phone's GPS [4]. Visiting a web page, regardless of whether you used an automated spider, clicked on a linked manually, perhaps even being tricked into doing it, or were framed by a malicious or compromised web site, can trigger an FBI raid [5] (remember goatse? Except it's worse, with a criminal record for you). There are also the dumb things people post themselves, for example on Facebook, causing them to lose jobs, opportunities for jobs, or even get arrested [6].
Regardless, people always think that happens only to others, that "they were dumb and I'm not" or that they are isolated incidents. This is why I was delighted to find this video of a law professor explaining why talking to police can be a bad idea [7]. Even though I knew that "everything you say can be used against you", I was surprised to learn that nothing you say can be used in your defense. This asymmetry is a rather convincing argument for exercising 5th amendment rights. Then there are the chances that even though you are innocent, due to the stress or excitement you will exaggerate or say something stupid. For example, you might say you've never touched a gun in your life -- except you did once a long time ago when you were a teen maybe, and forgot about it but there's a photo proving that you lied (apparently, that you didn't mean to lie matters little). People say stupid things in less stressful circumstances. Why take the chance? There are also coincidences that look rather damning and bad for you. Police sometimes make mistakes as well. The presentation is well-made and is very convincing; I recommend viewing it.
There are so many ways in which private information can be misinterpreted and used against you or to your disadvantage, and not just by police. Note that I agree that we need an effective police; however, there's a line between that and a surveillance society making you afraid to speak your mind in private, afraid to buy certain things at the grocery store, afraid to go somewhere or visit a web site, or afraid of chatting online with your friends, because you never know who will use anything you say or do against you and put it in the wrong context. In effect, you may be speaking to the police all the time but don't realize it. Even though considering each method separately, it can be argued that technically there isn't a violation of the 5th amendment, the cumulative effect may violate its intent.
Then, after I wrote most of this entry, Google CEO Eric Schmidt declared that "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place" [8]. I'm afraid that's a realistic assessment, even if it's a lawful activity, given the "spying guides" published by the likes of Yahoo!, Verizon, Sprint, Cox, SBC, Cingular, Nextel, GTE, Voicestream for law enforcement, and available at Cryptome [9]. The problem is that you'll then live a sad life devoid of personal liberties. The alternative shrug and ignorance of the risks is bliss, until it happens to you.
[1] Brandon Sprague (2004) Fireman attempted to set fire to house, charges say. Times Snohomish County Bureau, Seattle Times. Accessed at http://seattletimes.nwsource.com/html/localnews/2002055245_arson06m.html
[2] Mark Nestmann (2009) Yes, You ARE a Criminal…You Just Don't Know it Yet. In "Preserving your privacy and more", November 23 2009. Accessed at http://nestmannblog.sovereignsociety.com/2009/11/yes-you-are-a-criminalyou-just-dont-know-it-yet.html
[3] Chris Matyszczyk (2009) Court says police can use GPS to track anyone. Accessed at http://news.cnet.com/8301-17852_3-10237353-71.html
[4] Christopher Soghoian (2009) 8 Million Reasons for Real Surveillance Oversight. Accessed at http://paranoia.dubfire.net/2009/12/8-million-reasons-for-real-surveillance.html
[5] Declan McCullagh (2009) FBI posts fake hyperlinks to snare child porn suspects. Accessed at: http://news.cnet.com/8301-13578_3-9899151-38.html
[6] Mark Nestmann (2009) Stupid Facebook Tricks. In "Preserving your privacy and more", November 27 2009. Accessed at http://nestmannblog.sovereignsociety.com/2009/11/stupid-facebook-tricks.html
[7] James Duane (2008) Don't Talk to Police. http://www.youtube.com/watch?v=i8z7NC5sgik
[8] Ryan Tate (2009) Google CEO: Secrets Are for Filthy People. Accessed at http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people
[9] Cryptome. Accessed at http://cryptome.org/
Last edited Jan 25, as per emumbert1's suggestion (see comments).
Those kind of statements expose naïveté or, if intended as a manipulative statement, perversity. It takes a long time to explain the risks and convince others that they are real, and that they are really exposed to them, and what the consequences might be. Even if you could somehow manage to explain it convincingly on the spot, before you're done, chances are that you'll be dismissed as a "privacy nut". In addition, you rarely have that kind of time to make a point in a normal discussion. So, that fallacy is often a successful gambit simply because it discourages someone from trying to explain why it's so silly.
You may buy some time by mentioning anecdotes such as the man falsely accused of arson because by coincidence, he bought certain things in a store at a certain time (betrayed by his grocery loyalty card) [1]. Or, there's the Indiana woman who bought for her sick family just a little too much medication containing pseudoephedrine, an ingredient used in the manufacture of crystal meth [2]. Possibilities for the misinterpretation of data or the inappropriate enforcement of bad laws are multiplied by the ways in which it can be obtained. Police can stick a GPS-tracking device on anyone they want without getting a search warrant [3] or routinely use your own phone's GPS [4]. Visiting a web page, regardless of whether you used an automated spider, clicked on a linked manually, perhaps even being tricked into doing it, or were framed by a malicious or compromised web site, can trigger an FBI raid [5] (remember goatse? Except it's worse, with a criminal record for you). There are also the dumb things people post themselves, for example on Facebook, causing them to lose jobs, opportunities for jobs, or even get arrested [6].
Regardless, people always think that happens only to others, that "they were dumb and I'm not" or that they are isolated incidents. This is why I was delighted to find this video of a law professor explaining why talking to police can be a bad idea [7]. Even though I knew that "everything you say can be used against you", I was surprised to learn that nothing you say can be used in your defense. This asymmetry is a rather convincing argument for exercising 5th amendment rights. Then there are the chances that even though you are innocent, due to the stress or excitement you will exaggerate or say something stupid. For example, you might say you've never touched a gun in your life -- except you did once a long time ago when you were a teen maybe, and forgot about it but there's a photo proving that you lied (apparently, that you didn't mean to lie matters little). People say stupid things in less stressful circumstances. Why take the chance? There are also coincidences that look rather damning and bad for you. Police sometimes make mistakes as well. The presentation is well-made and is very convincing; I recommend viewing it.
There are so many ways in which private information can be misinterpreted and used against you or to your disadvantage, and not just by police. Note that I agree that we need an effective police; however, there's a line between that and a surveillance society making you afraid to speak your mind in private, afraid to buy certain things at the grocery store, afraid to go somewhere or visit a web site, or afraid of chatting online with your friends, because you never know who will use anything you say or do against you and put it in the wrong context. In effect, you may be speaking to the police all the time but don't realize it. Even though considering each method separately, it can be argued that technically there isn't a violation of the 5th amendment, the cumulative effect may violate its intent.
Then, after I wrote most of this entry, Google CEO Eric Schmidt declared that "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place" [8]. I'm afraid that's a realistic assessment, even if it's a lawful activity, given the "spying guides" published by the likes of Yahoo!, Verizon, Sprint, Cox, SBC, Cingular, Nextel, GTE, Voicestream for law enforcement, and available at Cryptome [9]. The problem is that you'll then live a sad life devoid of personal liberties. The alternative shrug and ignorance of the risks is bliss, until it happens to you.
[1] Brandon Sprague (2004) Fireman attempted to set fire to house, charges say. Times Snohomish County Bureau, Seattle Times. Accessed at http://seattletimes.nwsource.com/html/localnews/2002055245_arson06m.html
[2] Mark Nestmann (2009) Yes, You ARE a Criminal…You Just Don't Know it Yet. In "Preserving your privacy and more", November 23 2009. Accessed at http://nestmannblog.sovereignsociety.com/2009/11/yes-you-are-a-criminalyou-just-dont-know-it-yet.html
[3] Chris Matyszczyk (2009) Court says police can use GPS to track anyone. Accessed at http://news.cnet.com/8301-17852_3-10237353-71.html
[4] Christopher Soghoian (2009) 8 Million Reasons for Real Surveillance Oversight. Accessed at http://paranoia.dubfire.net/2009/12/8-million-reasons-for-real-surveillance.html
[5] Declan McCullagh (2009) FBI posts fake hyperlinks to snare child porn suspects. Accessed at: http://news.cnet.com/8301-13578_3-9899151-38.html
[6] Mark Nestmann (2009) Stupid Facebook Tricks. In "Preserving your privacy and more", November 27 2009. Accessed at http://nestmannblog.sovereignsociety.com/2009/11/stupid-facebook-tricks.html
[7] James Duane (2008) Don't Talk to Police. http://www.youtube.com/watch?v=i8z7NC5sgik
[8] Ryan Tate (2009) Google CEO: Secrets Are for Filthy People. Accessed at http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people
[9] Cryptome. Accessed at http://cryptome.org/
Last edited Jan 25, as per emumbert1's suggestion (see comments).
“Verified by VISA”: Still Using SSNs Online, Dropped by PEFCU
I have written before about the "Verified by VISA" program. While shopping for Thanksgiving online this year, I noticed that Verified by Visa scripts were blocked by NoScript, and I could complete my purchases without authenticating. It was tempting to conclude that the implementation was faulty, but a few phone calls clarified that the Purdue Employee Federal Credit Union stopped participating in the program. I have ambivalent feelings about this. I'm glad that PEFCU let us escape from the current implementation and surprise enrollment based on SSN at the time of purchase, and SSN-based password reset. Yet, I wish a password-protection system was in place because it could significantly improve security (see below). Getting such a system to work is difficult, because in addition to needing to enroll customers, both banks and merchants have to support it. For the sake of curiosity, I counted the number of participating stores in various countries, as listed on the relevant VISA web sites:
Multiply this by the fraction of participating banks (data not available for the US), and for a program that started in 2001, that's spotty coverage. Adoption would be better by getting people to enroll when applying for credit cards, when making a payment, by mail at any time, or in person at their bank. The more people adopt it, the more stores and banks will be keen on reducing their risk as the cost per participating card holder would decrease. Ambushing people at the time of an online purchase with an SSN request violates the security principle of psychological acceptability. The online password reset based on entering your SSN, which I had criticized, is still exposing people to SSN-guessing risks, and also the only means to change your password. I wish that VISA would overhaul the implementation and use an acceptable process (e.g., a nonce-protected link via email to a page with a security question). The reason I'm interested is because I'd rather have a password-protected credit card, and a single password to manage, than a hundred+ online shopping accounts that keep my credit card information with varying degrees of (in)security. Using an appropriate choke-point would reduce attack surface, memorization requirements, and identity theft.
| Country | Number of Stores |
|---|---|
| USA | 126 |
| Europe | 183 |
| Thailand | 439 |
| Taiwan | 144 |
| Japan | 105 |
| China | 90 |
| Singapore | 65 |
| Malaysia | 27 |
| Hong Kong | 20 |
| Vietnam | 17 |
| Australia | 13 |
| India | 7 |
| Others | 0 |
Firefox Vulnerabilities: Souvenirs of Windows 95
I've been waiting for an announcement of vulnerabilities in Firefox due to popular extensions. I've compared it to Windows 95 before. Yet students often opine that Firefox is more secure than Internet Explorer. It is worth repeating this explanation from the announcement:
"Mozilla doesn't have a security model for extensions and Firefox fully trusts the code of the extensions. There are no security boundaries between extensions and, to make things even worse, an extension can silently modify another extension."
Asking which of Firefox and Internet Explorer is most secure is like asking which of two random peasants is wealthier. They both might be doing their best and there may be significant differences but I wouldn't expect either to be a financier. While I'm running with this analogy, let me compare the widespread and often mandatory use of client scripts in websites (e.g., JavaScript) to CDOs: they both are designed by others with little interest in your security, they leverage your resources for their benefit, they are opaque, complex, nearly impossible to audit, and therefore untrustworthy. They have also both caused a lot of damage, as having scripting enabled is required for many attacks on browsers. How much smaller would botnets be without scripting? Like CDOs, scripting is a financial affair; it is needed to support advertising and measure the number of visitors and click-throughs. Scripting will stay with us because there's money involved, and if advertisers had their way, there would be no option to disable plugins and JavaScript, nor would there be extensions like NoScript. To be fair, there are beneficial uses for JavaScript, but it's a tangled mess with a disputable net value. Here's my take on media and advertising:
Every medium supported exclusively by advertising tends to have a net value of zero for viewers and users (viewsers?). This is where radio and TV are right now. If the value was significantly higher than zero, advertisers could wring more profits from it, for example by increasing the duration or number of annoying things, polluting your mind or gathering and exploiting more information. If it was significantly less than zero, then they would lose viewership and therefore revenue.
So, with time, and if advertising is allowed to power all websites through the requirement for scripting and JavaScript, surfing the web will become as pleasant, useful and watchable as TV, for example (with the difference that your TV can't be used --yet-- to attack people and other nations). I don't mind being locked out of websites that critically depend on advertising revenue -- just like I don't watch TV anymore because it has become a negative value proposition to me. However I mind being needlessly exposed to risks due to other people's decisions, when I use other websites. I'm looking forward to the "component directory lockdown" in Firefox 3.6 as a step in the right direction, and that's the bright light at the end of the tunnel: some things are improving.
"Mozilla doesn't have a security model for extensions and Firefox fully trusts the code of the extensions. There are no security boundaries between extensions and, to make things even worse, an extension can silently modify another extension."
Asking which of Firefox and Internet Explorer is most secure is like asking which of two random peasants is wealthier. They both might be doing their best and there may be significant differences but I wouldn't expect either to be a financier. While I'm running with this analogy, let me compare the widespread and often mandatory use of client scripts in websites (e.g., JavaScript) to CDOs: they both are designed by others with little interest in your security, they leverage your resources for their benefit, they are opaque, complex, nearly impossible to audit, and therefore untrustworthy. They have also both caused a lot of damage, as having scripting enabled is required for many attacks on browsers. How much smaller would botnets be without scripting? Like CDOs, scripting is a financial affair; it is needed to support advertising and measure the number of visitors and click-throughs. Scripting will stay with us because there's money involved, and if advertisers had their way, there would be no option to disable plugins and JavaScript, nor would there be extensions like NoScript. To be fair, there are beneficial uses for JavaScript, but it's a tangled mess with a disputable net value. Here's my take on media and advertising:
Every medium supported exclusively by advertising tends to have a net value of zero for viewers and users (viewsers?). This is where radio and TV are right now. If the value was significantly higher than zero, advertisers could wring more profits from it, for example by increasing the duration or number of annoying things, polluting your mind or gathering and exploiting more information. If it was significantly less than zero, then they would lose viewership and therefore revenue.
So, with time, and if advertising is allowed to power all websites through the requirement for scripting and JavaScript, surfing the web will become as pleasant, useful and watchable as TV, for example (with the difference that your TV can't be used --yet-- to attack people and other nations). I don't mind being locked out of websites that critically depend on advertising revenue -- just like I don't watch TV anymore because it has become a negative value proposition to me. However I mind being needlessly exposed to risks due to other people's decisions, when I use other websites. I'm looking forward to the "component directory lockdown" in Firefox 3.6 as a step in the right direction, and that's the bright light at the end of the tunnel: some things are improving.
Cassandra Firing GnuPG Blanks
A routine software update (a minor revision number) caused a serious problem. A number of blank messages were sent until we realized that attempts to sign messages with GnuPG from PHP resulted in empty strings. If you received a blank message from Cassandra, you can find out what it was about by logging to the service. Then click on the affected profile name (from the subject of the email), then "Search" and "this month". This will retrieve the latest alerts over an interval of one month for that profile. Messages will not be signed until we figure out a fix. We're sorry for the inconvenience.
Edit (Monday 11/2, noon): This has been fixed and emails are signed again. I also added a pre-flight test to detect this condition in the future.
The Secunia Personal Software Inspector
So you have all the patches from Microsoft applied automatically, Firefox updates itself as well as its extensions... But do you still have vulnerable, outdated software? Last weekend I decided to try the Secunia Personal Software Inspector, which is free for personal use, on my home gaming computer. The Secunia PSI helps find software that falls through the cracks of the auto-update capabilities. I was pleasantly surprised. It has a polished normal interface as well as an informative advanced interface. It ran quickly and found obsolete versions of Adobe Flash installed concurrently with newer ones, and pointed out that Firefox wasn't quite up-to-date as the latest patch hadn't been applied.
When I made the Cassandra system years ago, I was also dreaming of something like this. It is limited to finding vulnerable software by version, not configuration, and giving links to fixes; so it doesn't help hardening a system to the point that some computer security benchmarks can. However, those security benchmarks can decrease the convenience of using a computer, so they require judgment. It can also be time consuming and moderately complex to figure out what you need to do to improve the benchmark results. By contrast, the SPI is so easy to install and use that it should be considered by anyone capable of installing software updates, or anyone managing a family member's computer. The advanced interface also pointed out that there were still issues with Internet Explorer and with Firefox for which no fixes were available. I may use Opera instead until these issues get fixed. It is unfortunate that it runs only on Windows, though.
The Secunia Personal Software Inspector is not endorsed by Purdue University CERIAS; the above are my personal opinions. I do not own any shares or interests in Secunia.
Edit: fixed the link, thanks Brett!
When I made the Cassandra system years ago, I was also dreaming of something like this. It is limited to finding vulnerable software by version, not configuration, and giving links to fixes; so it doesn't help hardening a system to the point that some computer security benchmarks can. However, those security benchmarks can decrease the convenience of using a computer, so they require judgment. It can also be time consuming and moderately complex to figure out what you need to do to improve the benchmark results. By contrast, the SPI is so easy to install and use that it should be considered by anyone capable of installing software updates, or anyone managing a family member's computer. The advanced interface also pointed out that there were still issues with Internet Explorer and with Firefox for which no fixes were available. I may use Opera instead until these issues get fixed. It is unfortunate that it runs only on Windows, though.
The Secunia Personal Software Inspector is not endorsed by Purdue University CERIAS; the above are my personal opinions. I do not own any shares or interests in Secunia.
Edit: fixed the link, thanks Brett!
ReAssure 1.20 Release
A new version of the ReAssure testbed software, 1.20, is now available on the project web site. This version features a rewritten reservation manager that is multi-threaded, object-oriented, better commented, tested with PyLint, and responds to more queries from the web interface. The supporting serial switch communication library (soobml) was rewritten to be thread-safe, object-oriented and now supports multiple switches. Experiments are also started and stopped with much greater time precision. One small comment on PyLint: we allowed line lengths of 100. Lines of 80 characters are cramped when trying to provide meaningful error messages and referencing objects and invoking methods that have long, meaningful names. Our plans for the next release are to support user control of whether experimental PCs are allowed internet access. Currently only a specifically designated experimental PC is allowed access, for containment reasons.
Thanks to Ed Cates (CERIAS staff) for providing system administration services and helping with ReAssure. This work is supported by the National Science Foundation under Grant No. 0420906. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
Beware SQL libraries missing prepared statement support
Just because your library or framework allows you to specify an SQL query and the data separately, doesn't mean that it's sending data separately from code to the database.
Imagine this scenario. You read that prepared statements are a good way to avoid SQL injection, because the database is given code and data explicitly and separately. You chose a database that supports prepared statements. The library you use also seems to support them as you can pass SQL code and data as two separate arguments. However... internally the library just constructs a string and sends that to the database, and doesn't use the database's prepared statement support!
An example is the library "pyPGSQL", which supports PostGreSQL in Python. It has an "execute" command taking a query and parameters as separate arguments. However, internally it constructs a string to send off (after escaping the parameters, so it *shouldn't* be vulnerable):
self.res = self.conn.conn.query(_qstr % parms)
The point is that escaping on the client side, while most likely OK, isn't as robust as letting the database handle the data separately, by using prepared statements. This particularity of pyPGSQL has been known since 2003 (forum answer). However, it's good to point it out again, as I had started writing a program using pyPGSQL, thinking that my code would be fine. It's possible that others have as well. pyPGSQL doesn't claim to support prepared statements (the absence of a "prepare" instruction should have been a clue!). Nevertheless, it surprises me that there still exist libraries not supporting prepared statements and that don't state this with an unmistakable, large warning. I found surprisingly few Python libraries supporting prepared statements:
P.S.: Note that the work-around proposed in the forum link above does not provide the security of prepared statements properly supported by a library.
P.P.S.: To clarify, I haven't demonstrated an SQL injection vulnerability in pyPGSQL. It's not about the performance penalty either. It's about escaping done by the client library (the basic implementation of bind parameters without using the database's support) being a second-rate security solution to explicitly telling the database "here is the code. Now here's the data" (prepared statements). It's about decreasing code complexity and reducing chances for "misunderstandings" (and configuration, e.g., encoding, discrepancies). It's about assurance and choosing safer technologies and architectures.
P(3)S.: Why did I expect prepared statement support? Because the Python DBI 2.0 specification for the "execute" method suggests that implementations should be using prepared statements, at least internally:
One more thought is that I should be more positive and congratulate the people working on Python 3 for fixing this long-standing problem. They deserve kudos!
Imagine this scenario. You read that prepared statements are a good way to avoid SQL injection, because the database is given code and data explicitly and separately. You chose a database that supports prepared statements. The library you use also seems to support them as you can pass SQL code and data as two separate arguments. However... internally the library just constructs a string and sends that to the database, and doesn't use the database's prepared statement support!
An example is the library "pyPGSQL", which supports PostGreSQL in Python. It has an "execute" command taking a query and parameters as separate arguments. However, internally it constructs a string to send off (after escaping the parameters, so it *shouldn't* be vulnerable):
self.res = self.conn.conn.query(_qstr % parms)
The point is that escaping on the client side, while most likely OK, isn't as robust as letting the database handle the data separately, by using prepared statements. This particularity of pyPGSQL has been known since 2003 (forum answer). However, it's good to point it out again, as I had started writing a program using pyPGSQL, thinking that my code would be fine. It's possible that others have as well. pyPGSQL doesn't claim to support prepared statements (the absence of a "prepare" instruction should have been a clue!). Nevertheless, it surprises me that there still exist libraries not supporting prepared statements and that don't state this with an unmistakable, large warning. I found surprisingly few Python libraries supporting prepared statements:
- py-postgresql (unfortunately requires Python 3; was pg_proboscis for Python 2)
- Cristian Gafton's python-pgsql (not thread-safe)
P.S.: Note that the work-around proposed in the forum link above does not provide the security of prepared statements properly supported by a library.
P.P.S.: To clarify, I haven't demonstrated an SQL injection vulnerability in pyPGSQL. It's not about the performance penalty either. It's about escaping done by the client library (the basic implementation of bind parameters without using the database's support) being a second-rate security solution to explicitly telling the database "here is the code. Now here's the data" (prepared statements). It's about decreasing code complexity and reducing chances for "misunderstandings" (and configuration, e.g., encoding, discrepancies). It's about assurance and choosing safer technologies and architectures.
P(3)S.: Why did I expect prepared statement support? Because the Python DBI 2.0 specification for the "execute" method suggests that implementations should be using prepared statements, at least internally:
"A reference to the operation will be retained by the
cursor. If the same operation object is passed in again,
then the cursor can optimize its behavior. This is most
effective for algorithms where the same operation is used,
but different parameters are bound to it (many times)."
One more thought is that I should be more positive and congratulate the people working on Python 3 for fixing this long-standing problem. They deserve kudos!
Bad JavaScript, no CVE for you!
I'm flabbergasted to see Adobe release an advisory for a critical issue, using everything (BID & a "Vulnerability identifier") but a CVE identifier. I'm not surprised either that JavaScript support in Acrobat was involved in making its exploitation possible. Once again security folks tell people to "turn off JavaScript". It once seemed plausible to do in browsers, but these days even Purdue University makes it mandatory to enable JavaScript, as the tools we rely on for teaching (e.g., Blackboard) and other official Purdue pages don't work properly without JavaScript. Even the help system (!) doesn't work because the help link that could be just an HTML tag is actually implemented in JavaScript (and they also use the referrer tag to mitigate CSRF attacks, so no disabling that either). How long will it be before PDF documents can't be read without enabling JavaScript?
Overloaded Return Values Cause Bugs
In my secure programming class I have denounced the overloading of return values as a bad practice, and recently I discovered a new, concrete example of a bug (possibly a vulnerability) that results from this widespread practice. A search in the NVD and some googling didn’t reveal any mention of similar issues anywhere, but I probably just have missed them (I have trouble imagining that nobody else pointed that out before). In any case it may be worth repeating with this example.
The practice is to return a negative value to indicate an error, whereas a positive value has meaning, e.g., a length. Imagine a function looking like this:
int bad_idea(char *buf, unsigned int size) {
int length;
if (<some_error_condition>) {
length = -ERROR_CODE;
} else {
length = size; // substitute any operations that could overflow the signed int
}
return length;
}
This function could return random error values. Under the right conditions this could result in at least a DoS (imagine that this is a security-related function, e.g., for authentication). I suggest using separate channels to return error codes and meaningful values. Doing this lowers complexity in the assignment and meaning of that return value by removing the multiplexing. As a result:
There is an increased complexity in the function prototype, but the decreased ambiguity inside the function is beneficial. When the rest of the code uses unsigned integers, the likelihood of a signed/unsigned integer conversion mistake or an overflow is high. In the above example, the function is also defective because it is unable to process correctly some allowed inputs (because the input is unsigned and the output needs to be able to return the same range), so in reality there is no choice but to decouple the error codes from the semantic results (length). This discrepancy is easier to catch when the ambiguity of the code is decreased.
It does away with the bad practice of keeping the same variable for two uses: assigning error codes and negative values to a “length” is jarring;
It disambiguates the purpose and meaning of checking the “returned” values (I’m including the ones passed by reference, loosely using the word “returned”). Is it to check for an error or is it a semantic check that’s part of the business logic?
Integer overflows are a well-known problem; however in this case they are more a symptom of conflicting requirements. The incompatible constraints of having to return a negative integer for errors and an unsigned integer otherwise are really to blame; the type mismatch (“overflow”) is inevitable given those. My point is that the likelihood of developers getting confused and having bugs in their code, for example not realizing that they have incompatible constraints, is higher when the return value has a dual purpose.
Edit (10/13): It just occurred to me that vsnprintf and snprintf are in trouble, in both BSD and Linux. They return an int, but take an unsigned integer (size_t) as a size input, AND are supposed to return either the number of printed characters or a negative number if there’s an error. Even if the size can be represented as a signed integer, they return the number of characters that *would* have been printed if the size was infinite, so specifying a small size isn’t a fix. So it *might* be possible to make these functions seemingly return errors when none happened.
Note(10/14): I’ve been checking the actual code for snprintf. In FreeBSD, it checks both the passed size and the return value against INT_MAX and appears safe.
