I'm a research faculty member at a top 10 computer science department. I work with a lot of undergraduates as researchers and older students compare very favorably to their younger peers. In general tend to be much more diligent and focused. Most older students also seem willing to work through harder tasks without giving up. My sense from talking to employers is that I am not unique in my assessment.
I was in the Army for about 7 years (including a stint in the Persian Gulf in late 2003). The Army has deep, fundamental problems with how they treat techs.
I could go on for pages, but I'll just give one quick example. Promotions in the Army are based mostly on the amount of time you've been in your job. There are also "schools" that are for the most part mandatory to be promoted to the ranks of Sergeant and above. Attending one of these military schools, requires that you leave your unit for about a month. So within my job (74B) it was typical that 75% or more of the soldiers knew absolutely nothing technical. The problem was that there might only be 1 or 2 really savvy people in a unit and they couldn't afford to lose them for any point of time. So a friend of mine who ran the mail server for a large base, wasn't able to go to a military school so he got promoted much later than his non-tech savvy counterparts despite the fact he was a really good soldier as well.
This is a very common practice for the Army. The good techies (like my friend) leave the military instead of reenlisting because they have make 10x as much. Almost all of the high ranking enlisted people used to be infantry or medics or other non-technical fields who switched because they would get promoted faster in this job classification. For the most part they don't know or care about tech.
Of course, as an academic myself, not citing the paper for some software that I used, is sloppy anyway.
So you cite the paper for every piece of software you use (ssh, Linux, gcc, etc.)?
As a member of the networking / distributed systems community, researchers certainly don't cite all of the relevant tools they use. Testbeds (like Emulab and PlanetLab) and simulators (NS2, etc.) are cited in the results section because the reader needs to understand the methodology of experimentation. However many researchers use tools created by researchers to run their experiments (CoDeploy, PLuSH, PLMAN, Stork, etc.) and these are rarely cited because they do not alter the results.
The unfortunate reality is that citations are a metric of "credit" in the academic community and the lack of citations presents a problem for researchers who build tools.
It depends on what you mean by vulnerable. We tried cover this in the FAQ, but I'll repost a synopsis here.
1) Apt is certainly vulnerable to the endless data attack listed on the otherattacks page of the website. This crashes a box instead of allowing a malicious install. (The default of having a fairly large number of install sources increases the risk)
2) HTTPS is not used when talking to the security repo, so a man-in-the-middle can perform replay attacks for packages hosted by the security repo.
3) Mirror selection tools (netselect-apt, Software Sources, etc.) may remove the security repository from the list of used sources. Users should be made aware of this.
In general, we think that apt's signatures on the repository metadata are the right thing to do (assuming replay / freezing protection is added).
We also looked a little at the information we could find about Debian's developer update process (this is mentioned in the TR linked to from our website). We would be interested to hear your feedback if you'd like to email our project email address with any comments.
Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.
Using P2P has other issues. Our webpage doesn't talk about this because we don't have a clever solution in place yet, but as wily slashdotters have mentioned there is also a disclosure problem. When are updating a package, you disclose to an untrusted entity (a mirror) that you are likely to have an outdated package installed. Using P2P exasperates this effect because you are now disclosing this to a larger number of people. As such, I'm not sure it's a security win to use DebTorrent.
Personally, I think that openSUSE provides a good solution in this space by having signed repository metadata downloaded from their main repository and packages downloaded from mirrors. However, it would be nice if they would add HTTPS support to protect against man-in-the-middle attackers when retrieving the repository metadata.
Yum's mirror selection scheme MirrorManager isn't by random and allows an attacker to do nasty things. Suppose I know your company has IP addresses 1.2.3.0/24. I can set up an Fedora mirror and then select that I want to serve content to the subnet 1.2.3.0/24. My mirror will be the _only_ mirror a user with one of those IPs will use. This can be used to easily target attacks to governments, military computers, etc.
if you picked your own mirror, you already trust them.
While this is a fairly common opinion, we believe this is the wrong security model for package distribution. I mean, if you trust your mirror, why sign packages in the first place? I would argue that if a distribution is going to support outside mirrors it needs to ensure that a mirror cannot compromise the security of the clients in any worse way than refusing to serve requests.
Also it's worth noting that there are many tools like Source Selector, netselect-apt, etc. which automatically choose a single mirror for you based upon bandwidth, etc. An attacker with a well provisioned system could obtain a huge number of clients.
Part of the confusion may be with the term metadata. There are two types of metadata which I'll call package and repository metadata. The package metadata describes a package (foo is version 1.2, has size 34K, needs the package bar, etc.) and is typically extracted from the package itself and provided in a tarball on the repository (for dependency resolution). The repository metadata describes where on the repository one can find the packages, and tarballs of package metadata(*).
In yum (which I will assume you are using since it's the most popular RPM based package manager and you refer to rpms) there are no signatures on the repository metadata or package metadata. There are signatures on the packages themselves, but not the extracted package metadata.
The fundamental way the replay attack works is that I can have my mirror host outdated versions of packages that are correctly signed. I can use an old repository metadata file or write my own repository metadata file that refers to package metadata and packages that are out of date. A client may ask to install firefox and I would provide a correctly signed version of firefox-2.0. Clearly if this package contains a vulnerability that I can exploit remotely, I now can control your system.
The fact that the package metadata in the tarballs isn't signed also enables some other attacks. Yum will blindly trust any package metadata it receives. So when you download the package metadata for firefox, I can modify the package metadata to say it depends on additional packages (which will cause you to install them as well), say that it has a dependency on a package that does not exist (which prevents you from installing firefox at all), or return a huge list of packages to attack another repository (details on website / papers). Yum does not check any signature until after it finished dependency resolution and downloads all of the packages.
Surprisingly yum does not verify that the package metadata it received from the repository matches the metadata embedded in the signed package. So if I say firefox depends on apache (both packages correctly signed), yum will install both even though after downloading it could check the firefox RPM to see it doesn't depend on apache.
We think that the right way to tackle this problem isn't to sign the package metadata, but the repository metadata. Since the repository metadata has the secure hash of the package metadata (in most repository layouts), signing the repository metadata covers all of the content on the mirror / repo. We advocate using timestamps and expiration times to prevent an attacker from providing an older but correctly signed version of the repository metadata or freezing the metadata perpetually. (please see our papers for more information)
Anyways, we understand the skepticism and appreciate the spirited emails and slashdot comments we've received about these vulnerabilities!
Justin Cappos
(*) Not all package managers download package metadata in separate tarballs (some actually scrape information from the headers of the packages on the repository). Regardless of how the information is stored, if it's not signed then an attacker can substitute malicious data. I'm simplifying here to make the discussion clearer and more generally applicable to a wide range of package managers.
Conversely, NAT, Proxy servers, CDNs (like Coral, CoDeeN), etc. decrease the number of IP addresses that access a page while having a large number of users see the content...
For instance, district-by-district vote totals add up to 292,267 votes for President Bush, but his official total was only 190,889.
Election officials have an explanation. Early votes for statewide candidates were not recorded by House district but rather were tallied for each of the state's four election regions.
My observation:
If this is true, shouldn't 292267 minus 190889 be divisible by 3 (considering these votes were counted three extra times)?
Slashdot Mirror
I'm a research faculty member at a top 10 computer science department. I work with a lot of undergraduates as researchers and older students compare very favorably to their younger peers. In general tend to be much more diligent and focused. Most older students also seem willing to work through harder tasks without giving up. My sense from talking to employers is that I am not unique in my assessment.
I was in the Army for about 7 years (including a stint in the Persian Gulf in late 2003). The Army has deep, fundamental problems with how they treat techs.
I could go on for pages, but I'll just give one quick example. Promotions in the Army are based mostly on the amount of time you've been in your job. There are also "schools" that are for the most part mandatory to be promoted to the ranks of Sergeant and above. Attending one of these military schools, requires that you leave your unit for about a month. So within my job (74B) it was typical that 75% or more of the soldiers knew absolutely nothing technical. The problem was that there might only be 1 or 2 really savvy people in a unit and they couldn't afford to lose them for any point of time. So a friend of mine who ran the mail server for a large base, wasn't able to go to a military school so he got promoted much later than his non-tech savvy counterparts despite the fact he was a really good soldier as well.
This is a very common practice for the Army. The good techies (like my friend) leave the military instead of reenlisting because they have make 10x as much. Almost all of the high ranking enlisted people used to be infantry or medics or other non-technical fields who switched because they would get promoted faster in this job classification. For the most part they don't know or care about tech.
Is UDLD on? Sounds like it might be a forwarding loop.
Of course, as an academic myself, not citing the paper for some software that I used, is sloppy anyway.
So you cite the paper for every piece of software you use (ssh, Linux, gcc, etc.)?
As a member of the networking / distributed systems community, researchers certainly don't cite all of the relevant tools they use. Testbeds (like Emulab and PlanetLab) and simulators (NS2, etc.) are cited in the results section because the reader needs to understand the methodology of experimentation. However many researchers use tools created by researchers to run their experiments (CoDeploy, PLuSH, PLMAN, Stork, etc.) and these are rarely cited because they do not alter the results.
The unfortunate reality is that citations are a metric of "credit" in the academic community and the lack of citations presents a problem for researchers who build tools.
There is an excellent research paper on the vulnerabilities in software updaters available at: http://www.cs.duke.edu/usenix/06hotsec/tech/bellissimo.html
1) Apt is certainly vulnerable to the endless data attack listed on the otherattacks page of the website. This crashes a box instead of allowing a malicious install. (The default of having a fairly large number of install sources increases the risk)
2) HTTPS is not used when talking to the security repo, so a man-in-the-middle can perform replay attacks for packages hosted by the security repo.
3) Mirror selection tools (netselect-apt, Software Sources, etc.) may remove the security repository from the list of used sources. Users should be made aware of this.
In general, we think that apt's signatures on the repository metadata are the right thing to do (assuming replay / freezing protection is added).
We also looked a little at the information we could find about Debian's developer update process (this is mentioned in the TR linked to from our website). We would be interested to hear your feedback if you'd like to email our project email address with any comments.
Justin Cappos
Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.
Using P2P has other issues. Our webpage doesn't talk about this because we don't have a clever solution in place yet, but as wily slashdotters have mentioned there is also a disclosure problem. When are updating a package, you disclose to an untrusted entity (a mirror) that you are likely to have an outdated package installed. Using P2P exasperates this effect because you are now disclosing this to a larger number of people. As such, I'm not sure it's a security win to use DebTorrent.
Personally, I think that openSUSE provides a good solution in this space by having signed repository metadata downloaded from their main repository and packages downloaded from mirrors. However, it would be nice if they would add HTTPS support to protect against man-in-the-middle attackers when retrieving the repository metadata.
Justin Cappos
if you picked your own mirror, you already trust them.
While this is a fairly common opinion, we believe this is the wrong security model for package distribution. I mean, if you trust your mirror, why sign packages in the first place? I would argue that if a distribution is going to support outside mirrors it needs to ensure that a mirror cannot compromise the security of the clients in any worse way than refusing to serve requests.
Also it's worth noting that there are many tools like Source Selector, netselect-apt, etc. which automatically choose a single mirror for you based upon bandwidth, etc. An attacker with a well provisioned system could obtain a huge number of clients.
Justin Cappos
In yum (which I will assume you are using since it's the most popular RPM based package manager and you refer to rpms) there are no signatures on the repository metadata or package metadata. There are signatures on the packages themselves, but not the extracted package metadata.
The fundamental way the replay attack works is that I can have my mirror host outdated versions of packages that are correctly signed. I can use an old repository metadata file or write my own repository metadata file that refers to package metadata and packages that are out of date. A client may ask to install firefox and I would provide a correctly signed version of firefox-2.0. Clearly if this package contains a vulnerability that I can exploit remotely, I now can control your system.
The fact that the package metadata in the tarballs isn't signed also enables some other attacks. Yum will blindly trust any package metadata it receives. So when you download the package metadata for firefox, I can modify the package metadata to say it depends on additional packages (which will cause you to install them as well), say that it has a dependency on a package that does not exist (which prevents you from installing firefox at all), or return a huge list of packages to attack another repository (details on website / papers). Yum does not check any signature until after it finished dependency resolution and downloads all of the packages.
Surprisingly yum does not verify that the package metadata it received from the repository matches the metadata embedded in the signed package. So if I say firefox depends on apache (both packages correctly signed), yum will install both even though after downloading it could check the firefox RPM to see it doesn't depend on apache.
We think that the right way to tackle this problem isn't to sign the package metadata, but the repository metadata. Since the repository metadata has the secure hash of the package metadata (in most repository layouts), signing the repository metadata covers all of the content on the mirror / repo. We advocate using timestamps and expiration times to prevent an attacker from providing an older but correctly signed version of the repository metadata or freezing the metadata perpetually. (please see our papers for more information)
Anyways, we understand the skepticism and appreciate the spirited emails and slashdot comments we've received about these vulnerabilities!
Justin Cappos
(*) Not all package managers download package metadata in separate tarballs (some actually scrape information from the headers of the packages on the repository). Regardless of how the information is stored, if it's not signed then an attacker can substitute malicious data. I'm simplifying here to make the discussion clearer and more generally applicable to a wide range of package managers.
This also is still a problem for new package installs...
Conversely, NAT, Proxy servers, CDNs (like Coral, CoDeeN), etc. decrease the number of IP addresses that access a page while having a large number of users see the content...
Not trying to troll here, but can someone explain why Cooking Mama is supposed to be fun?
Why not cook real meals (at a job or for the homeless) instead?
From the article:
For instance, district-by-district vote totals add up to 292,267 votes for President Bush, but his official total was only 190,889.
Election officials have an explanation. Early votes for statewide candidates were not recorded by House district but rather were tallied for each of the state's four election regions.
My observation:
If this is true, shouldn't 292267 minus 190889 be divisible by 3 (considering these votes were counted three extra times)?
The answer (101378) isn't...
http://www.ipspotting.com/?IP=65.212.151.113 or http://ws3.dessol.com/?IP=219.95.244.199 Since when does a royal flush have a 3?