Weblog entry #85 for dkg
See all weblog entries made by dkg.
#85
Compromising webapps: a case study
Posted by dkg on Fri 16 Mar 2012 at 01:42
This paper should be required reading for anyone developing, deploying, or administering web applications.
It's also interesting to read the perspective of the folks operating the compromised webapp (details are in the section titled "Digital Vote-By-Mail" on pages 34 to 38).
Comments on this Entry
Posted by Anonymous (87.238.xx.xx) on Thu 22 Mar 2012 at 11:27
FTA:
However, the ability of hackers to compromise the public test systems was precipitated by the following factors:
- Use of poorly tested components available from the open source community
- Release of source code
---
They are claiming that releasing source code harms security instead of improving it.
However, the ability of hackers to compromise the public test systems was precipitated by the following factors:
- Use of poorly tested components available from the open source community
- Release of source code
---
They are claiming that releasing source code harms security instead of improving it.
[ Parent | Reply to this comment ]
Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 22 Mar 2012 at 16:07
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Yep -- i think that Wolchok et al. neatly lay that argument to rest in section 5.2:
Despite these problems, one of the strongest logistical aspects of the D.C. trial was that access to the code -- and to some extent, the architecture -- was available to the testers. While some observers have suggested that this gave us an unrealistic advantage while attacking the system, there are several reasons why such transparency makes for a more realistic test. Above and beyond the potential security benefits of open source code (pressure to produce better code, feedback from community, etc.), in practice it is difficult to prevent a motivated attacker from gaining access to source code. The code could have been leaked by the authors through an explicit sale by dishonest insiders, as a result of coercion, or through a compromised developer workstation. Since highly plausible attacks such as these are outside the scope of a research evaluation, it is not only fair but realistic to provide the code to the testers.
[ Parent | Reply to this comment ]
No. The argument that code might have been available depends on a condition, and thus it is less likely to happen in the wild and thus is a logically flawed argument. It suffers the same flaw as religious apologetics, or theory saving in science.
The correct argument in favour of source code availability in IT security is that availability encourages correct code and methods as well as allowing 3rd party code inspection. In this case it seems this process had already happened they just failed to run the corrected code.
I suspect the reality is that for core free software applications you gain security because things like the Linux kernel, GNU file utilities, Apache, and Wordpress have received extensive 3rd party code analysis and testing. For lesser used Web Applications it may work against you. You also gain security where code availability allows some other positive behaviour such as recompilation allowing additional security features - see for example the Debian goal for the next release to add compiler flags to harden executables.
Whether the net effect is a gain or loss can only be determined by observation, and it is possible the net effect will change over time, across fields, and across software providers.
The correct argument in favour of source code availability in IT security is that availability encourages correct code and methods as well as allowing 3rd party code inspection. In this case it seems this process had already happened they just failed to run the corrected code.
I suspect the reality is that for core free software applications you gain security because things like the Linux kernel, GNU file utilities, Apache, and Wordpress have received extensive 3rd party code analysis and testing. For lesser used Web Applications it may work against you. You also gain security where code availability allows some other positive behaviour such as recompilation allowing additional security features - see for example the Debian goal for the next release to add compiler flags to harden executables.
Whether the net effect is a gain or loss can only be determined by observation, and it is possible the net effect will change over time, across fields, and across software providers.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]