Security
Brief items
What is "unauthorized access"?
Much of a security-oriented administrator's work has to do with the prevention of unauthorized access to a set of computing resources. So it is interesting to note that, as laid out in this paper by Orin S. Kerr, few people have really tried to nail down what "unauthorized access" really means. The paper discusses the issue in great detail; it is 80 pages long, and the author uses more footnotes than Lawrence Lessig or Terry Pratchett. After looking over a few decades of (U.S.) case law and legislation, he puts forward a couple of recommendations which, it is hoped, will help the courts achieve some sort of rational interpretation of the wide variety of computer crime laws in the U.S.The question of "access" is not as straightforward as one might think. Robert Morris (of the famous Morris Worm) tried to argue that he did not "access" all of the systems that his worm infected. Instead, he only accessed the systems where he launched the worm - and he had legitimate accounts there. The court didn't buy it, but the question remains. Back when the only way to get onto a system remotely was via modem, the act of "accessing" a computer was relatively straightforward. In the current world, however, does somebody "access" a computer by opening an ssh connection, pulling down a web page, sending an email, or sending a ping packet? Did you, gentle reader, "access" the numerous routers these words passed through on the way to your browser?
Once you have a handle on what it means to access a computer, it's time to figure out what "unauthorized" means. Courts have found, for example, that a disgruntled programmer who deleted code from his employer's system engaged in unauthorized access, while a police officer who printed out drivers license photographs of female college students did not. A system administrator who password-protected a set of files was also found to have not engaged in unauthorized access. Violation of an ISP's or web site's terms of service has often been found to be unauthorized access. Verio was found to have made unauthorized accesses to Register.com's whois database for the simple reason that Register.com didn't like it.
Mr. Kerr fears that overly broad interpretations of "unauthorized access" could eventually criminalize the everyday behavior of millions of net users. His recommendations are:
-  "Access" should be interpreted broadly.  "
...I propose that a user accesses a computer any time the user sends a command to that computer that the computer executes. In effect, I would define access as any successful interaction with the computer.
" Pinging the computer, or reaching a login screen, would be sufficient. -  The definition of "unauthorized" should be much more narrow.
     "
I propose that courts limit access 'without authorization' to accesses that circumvent restrictions by code. Breaches of regulation by contract should as a matter of law be held to be insufficient grounds for access to be considered 'without authorization.'
" 
In other words, the author is proposing an anti-circumvention law for computing systems. In this case, anti-circumvention makes some sense; access controls serve as the "lock on the door" of a computer that belongs to somebody else. A person who breaks that lock cannot claim to have authorization. But a person who has simply gone against somebody's wish for how a computer should be used (violating terms of service, sending spam, "deep linking," etc.) should be dealt with using contract law. Nobody should face possible jail time for deep linking.
The proposed interpretation has its own interesting issues, of course. For example, a denial of service attack is not necessarily an unauthorized access (though it can certainly violate other laws). Would sending spam which has been specially crafted to evade filters be circumvention of code-based access control? These questions remain tricky to answer. By looking at them closely, however, we at least stand a chance of having a better idea of what we are talking about.
New vulnerabilities
kernel 2.4 - two new vulnerabilities
| Package(s): | kernel | CVE #(s): | CAN-2003-0244 CAN-2003-0246 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 14, 2003 | Updated: | July 25, 2003 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The 2.4.20 (and prior) kernel contains a couple of vulnerabilities that are worth fixing.  
 
  | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: | 
               
  | ||||||||||||||||||||||||||||||||||||||||||||||||||
kopete: vulnerabiliy in GnuPG plugin
| Package(s): | kopete | CVE #(s): | CAN-2003-0256 | ||||||||||||
| Created: | May 8, 2003 | Updated: | June 27, 2003 | ||||||||||||
| Description: | A vulnerability was discovered in versions of kopete prior to 0.6.2. Kopete is a KDE instant messenger client. This vulnerabiliy is in the GnuPG plugin that allows for users to send each other GPG-encrypted instant messages. The plugin passes encrypted messages to gpg, but does no checking to sanitize the commandline passed to gpg. This can allow remote users to execute arbitrary code, with the permissions of the user running kopete, on the local system. | ||||||||||||||
| Alerts: | 
               
  | ||||||||||||||
xinetd: Memory leak in xinetd 2.3.10
| Package(s): | xinetd | CVE #(s): | CAN-2003-0211 | ||||||||||||||||||||
| Created: | May 13, 2003 | Updated: | November 13, 2003 | ||||||||||||||||||||
| Description: | Xinetd is a 'master server' that is used to to accept service connection
requests and start the appropriate servers.
 Because of a programming error, memory was allocated and never freed if a connection was refused for any reason. An attacker could exploit this flaw to crash the xinetd server, rendering all services it controls unavailable. In addition, other flaws in xinetd could cause incorrect operation in certain unusual server configurations. All users of xinetd are advised to update to xinetd-2.3.11 which is not vulnerable to these issues.  | ||||||||||||||||||||||
| Alerts: | 
               
  | ||||||||||||||||||||||
Resources
Page editor: Jonathan Corbet
Next page:
                  Kernel development>>
                  
           