It would help other Debian users if you either submitted a bug report to the upgrade-reports package describing your expirience and the problems you encountered, or, even better, a bug to the release-notes package to document these issues. Some of them might even be fixed for the next point release, and the bugs will be forwarded to the package maintainers so that etch's packages are fixed. Contributing these issues back to developers is really simple, just read http://www.debian.org/releases/stable/reportingbug s
It will be integrated in the latest version of the Debian installer, IIRC, it will be in 'etch beta 3'. Which should be available soon (check out the
PartmanCrypto stuff in the wiki and the Debian Installer pages). Since Ubuntu uses a derived version from the installer, they will presumely pick this up once it is finished.
Actually, Debian developers do more. (approx) 250 Debian Developers have recently (two weeks ago) attended this year's Debian Conference in Mexico. Not everybody hacked all the time (as the pictures proved) but there was quite a bit of it.
Also, even if the main conference is held yearly, there are mini conferences held with fewer people (30-100) in, at least, Australia, Japan and Spain.
In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as me... great... so you can log take all my money? I mean there may be some strange setup that this can be used to exploit but I should think it's a rarity.
You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the session ID generated in a non authenticated area. This can lead to session fixation attacks, and, consequentely, to impersonation attacks. A malicious user could log in as a the user he "fixed" the session to.
Here's how it is done:
user A visits a malicious site property of user B
malicious user's B software generates a valid session cookie for site X
(valid can be just properly formated, a valid hash or a cookie obtained
from the site by accessing it without any authentication it depends on
the application, really). This can be either static or dynamic
user A is provided a modified session cookie from site X (expiration date is set very far in the future) and the software keeps track of which user's have been given which cookies.
user A, later in the fure, goes to site X
site X does not issue a new cookie, the user's browser already provided one
user A logs in to site X
site X associates the session with the user authentication (like, say, store the session ID in a table matching session to user like many PHP scripts do or storing this in a servlet context)
user A uses the site
malicious user B goes to site X with the session cookie he provided to user A and can bypass the site authentication.
So the malicious user can impersonate the user at the site without authentication.
Of course, the problem here is with the site (steps 5 and 7), it should regenerate session identifiers, at the very least, when a user logs in. That way the authentication is associated with the new session, not the old one. However, you would be amazed to see how many sites (even banks) reuse the session identifier generated in a non-authenticated throughout a user's session, and only regenerate it when it's marked as invalid (authentication session timeout expired).
The scenario differs in the case you are handling software in which session identifiers expire even if not associated with a user session (Notice this is not typically the case for many application servers, as they don't include timestamps in sessions, typically applications will be in charge of expiring the session for authenticated users). In this scenario the malicious user B just needs to obtain the cookie from the remote server when the user A accesses his own malicious server and then redirect the user to the login of the site. This makes the attack a modified version of the traditional phishing attack, in this attack you are not asking for user's credentials since you do not need them to access the site once the user is logged in (the session ID is sufficient to access the site).
You would say that there is a loophole in EULAs when companies pirate software? Because that's just the same loophole, it's a copyright violation, and it's illegal. Closing-sourcing the "rules" was the first move by Tenable and Source to try to prevent this piracy from other security vendors of their knowledge (some software vendors even copy & pasted their rules onto their IDS/IPS products with minimum changes). Do you really believe that someone who pirates the GPL is even afraid of piracing a more restrictive license? I don't think so.
It's not based on SATAN, it's a fork, and it has relicensed the code (from a non-free license to a GPL license) without the author's permission. I suggest you look elsewhere...
SATAN and SAINT were never free (please read their license, I know, I packaged them for Debian and eventually dropped them. The first one because it was non-free, the second one because it claimed to be GPL when it was an unauthorised SATAN fork. Same for SARA. Sure, they have s/satan/saint/g or s/satan/sara/g (even on the script names) if anyone wants to compare sources, let me know, I've been tracking all of them since SATAN was last released.
It just seems that Dan Farmer and Wietse Venema don't care about these forks, they abandoned SATAN a long time ago (it's not even available in fish.com anymore, the domain is no more). I know, I contacted them.
You fail to see two sides of Nessus here, which might lead to it being eventually being dropped from Debian. Be it a vulnerability scanner, an antivirus or an IDS yo uhave:
Quite sincerely, If I were the Debian maintainer (ehem), I would consider dropping support for both packages in Debian even though I believe it would be as much a loss to Debian users as to the projects themselves (less user-base => less exposure => less bug reports => less enhancements =>.... => product dead?). It seems that Sourcefire, however, now has Check Point to sustain the project and fund its development even if the OSS crowd turns away from it.
I'm amazed that people don't read the Release Notes even if they are available for all eleven architectures and translated to 14 different languages. The recommended method for upgrade is aptitude not apt-get. It has shown that it has better dependency solving for complex issues (such as a dist-upgrade).
Please go through the Release Notes, the relevant chapter is Upgrades from previous releases (link goes to english version for i386).
I'm not fully involved in that project for the moment since I'm already bogged down by other work. I've had some e-mail coversations with Lorenzo in order to first know _what_ would the project mean as I (like others) wouldn't like to see another fork (just what happened with Adamantix) but would like to see the work done at Adamantix be brought up into Debian proper and this could be a good opportunity. Notice that some of this work (such as their kernel patches and PaX utilities) is already available in Debian.
Recompiling the whole distribution with a gcc-enabled SPP (with the Debian packages developed by Steve Kemp for example) is a complex issue and needs some deep internal changes that we have yet to discuss. Doing so in source-based distributions (like with Hardened Gentoo) is easier, after all, AFAIK they don't provide binaries for 11 architectures like Debian does.
As for SNARE in Debian, the only reason there are no available SNARE packages in Debian (version 0.9.1 in experimental) is just because of my lack of time in order to produce those. On top of that, there has been few interest and demand, if any, for SNARE packages in Debian by Debian users. For an example check the bugs reported in the BTS, and, yes, I've been also slow in fixing bugs there.
If you would be willing to help co-maintain a set of packages for Debian we could probably review your packages and have them available in the unstable and, eventually, in the stable distribution.
Certification is not a question of technical merit, it's also based on a lot of paperwork as well as a lot of money that needs to be "given" to a certification laboratory that validates all that paperwork
I've been pushing for a Debian CC certification myself, but it's not probable that this will come to pass unless it's sponsored.
You do have a Debian-derived product that is currently CC certified EAL4: Stonesoft's Stonegate (security target available at NIST's NIAP, the Common Criteria site seems to have been discontinued unfortunately). It is certified versus a firewall-specific Protection Profile, though, so it should not be used as a comparison metric against others that are certified against an operating system PP.
As described in a Debian Planet article the following servers are currently offline:
master (bugs), murphy (lists), and gluck (www, cvs) . Notice that klecker (www-master, security, web-search, non-us) was offline too but is now working after admins have re-installed it (from scratch). This was also mentioned in the Official announcement
As mentioned in order comment Wichert Akkerman has setup a page explaining the current situation at http://www.wiggy.net/debian/
Notice that you will not find a note in the www.debian.org web server since until all the servers are being restored and are back online a public note (giving more details than the previous announcement) is being postponed. Also, the infraestructure used to build up the web site (english + all the translations) is part of the compromised servers.
The problem with the old TAMU version is that it was getting as out of date as SATAN was. It still is a good framework and has lots of room for improvement.
Also, it's the only tool of that time that is completely free. SATAN, COPS and ISS are either outdated or no longer free and new replacements have appeared for some of them (Nessus).
> What does Tiger do that all of the above listed
> programs don't do?
Tiger it is not a logchecker, nor it focused in integrity analysis. It does "the other stuff", it checks the system configuration and status.
Just read the manpage (and it's not fully up to date, i.e, it does not include the new checks). I bet you will be surprised. For example, it has a module that can determine which network servers you are running are using deleted files (because you patched the libraries through a package upgrade but the server was not restarted).
As for system security checks that Tiger provides that others do not you can read this (short) comparison.
Slashdot Mirror
It would help other Debian users if you either submitted a bug report to the upgrade-reports package describing your expirience and the problems you encountered, or, even better, a bug to the release-notes package to document these issues. Some of them might even be fixed for the next point release, and the bugs will be forwarded to the package maintainers so that etch's packages are fixed. Contributing these issues back to developers is really simple, just read http://www.debian.org/releases/stable/reportingbug s
It will be integrated in the latest version of the Debian installer, IIRC, it will be in 'etch beta 3'. Which should be available soon (check out the PartmanCrypto stuff in the wiki and the Debian Installer pages). Since Ubuntu uses a derived version from the installer, they will presumely pick this up once it is finished.
Actually, Debian developers do more. (approx) 250 Debian Developers have recently (two weeks ago) attended this year's Debian Conference in Mexico. Not everybody hacked all the time (as the pictures proved) but there was quite a bit of it.
Also, even if the main conference is held yearly, there are mini conferences held with fewer people (30-100) in, at least, Australia, Japan and Spain.
You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the session ID generated in a non authenticated area. This can lead to session fixation attacks, and, consequentely, to impersonation attacks. A malicious user could log in as a the user he "fixed" the session to.
Here's how it is done:
So the malicious user can impersonate the user at the site without authentication.
Of course, the problem here is with the site (steps 5 and 7), it should regenerate session identifiers, at the very least, when a user logs in. That way the authentication is associated with the new session, not the old one. However, you would be amazed to see how many sites (even banks) reuse the session identifier generated in a non-authenticated throughout a user's session, and only regenerate it when it's marked as invalid (authentication session timeout expired).
The scenario differs in the case you are handling software in which session identifiers expire even if not associated with a user session (Notice this is not typically the case for many application servers, as they don't include timestamps in sessions, typically applications will be in charge of expiring the session for authenticated users). In this scenario the malicious user B just needs to obtain the cookie from the remote server when the user A accesses his own malicious server and then redirect the user to the login of the site. This makes the attack a modified version of the traditional phishing attack, in this attack you are not asking for user's credentials since you do not need them to access the site once the user is logged in (the session ID is sufficient to access the site).
For more info check out WebApp Security threat definition for session fixation Chris Shiflett: Security Corner: Session Fixation
You would say that there is a loophole in EULAs when companies pirate software? Because that's just the same loophole, it's a copyright violation, and it's illegal. Closing-sourcing the "rules" was the first move by Tenable and Source to try to prevent this piracy from other security vendors of their knowledge (some software vendors even copy & pasted their rules onto their IDS/IPS products with minimum changes). Do you really believe that someone who pirates the GPL is even afraid of piracing a more restrictive license? I don't think so.
It's not based on SATAN, it's a fork, and it has relicensed the code (from a non-free license to a GPL license) without the author's permission. I suggest you look elsewhere...
SATAN and SAINT were never free (please read their license, I know, I packaged them for Debian and eventually dropped them. The first one because it was non-free, the second one because it claimed to be GPL when it was an unauthorised SATAN fork. Same for SARA. Sure, they have s/satan/saint/g or s/satan/sara/g (even on the script names) if anyone wants to compare sources, let me know, I've been tracking all of them since SATAN was last released.
It just seems that Dan Farmer and Wietse Venema don't care about these forks, they abandoned SATAN a long time ago (it's not even available in fish.com anymore, the domain is no more). I know, I contacted them.
You fail to see two sides of Nessus here, which might lead to it being eventually being dropped from Debian. Be it a vulnerability scanner, an antivirus or an IDS yo uhave:
An engine without rules is not useful at all. And Tenable closed-source those already a while back. Just like Sourcefire closed sourced the Snort rules.
Quite sincerely, If I were the Debian maintainer (ehem), I would consider dropping support for both packages in Debian even though I believe it would be as much a loss to Debian users as to the projects themselves (less user-base => less exposure => less bug reports => less enhancements => .... => product dead?). It seems that Sourcefire, however, now has Check Point to sustain the project and fund its development even if the OSS crowd turns away from it.
I'm amazed that people don't read the Release Notes even if they are available for all eleven architectures and translated to 14 different languages. The recommended method for upgrade is aptitude not apt-get. It has shown that it has better dependency solving for complex issues (such as a dist-upgrade).
Please go through the Release Notes, the relevant chapter is Upgrades from previous releases (link goes to english version for i386).
I'm not fully involved in that project for the moment since I'm already bogged down by other work. I've had some e-mail coversations with Lorenzo in order to first know _what_ would the project mean as I (like others) wouldn't like to see another fork (just what happened with Adamantix) but would like to see the work done at Adamantix be brought up into Debian proper and this could be a good opportunity. Notice that some of this work (such as their kernel patches and PaX utilities) is already available in Debian.
Recompiling the whole distribution with a gcc-enabled SPP (with the Debian packages developed by Steve Kemp for example) is a complex issue and needs some deep internal changes that we have yet to discuss. Doing so in source-based distributions (like with Hardened Gentoo) is easier, after all, AFAIK they don't provide binaries for 11 architectures like Debian does.
As for SNARE in Debian, the only reason there are no available SNARE packages in Debian (version 0.9.1 in experimental) is just because of my lack of time in order to produce those. On top of that, there has been few interest and demand, if any, for SNARE packages in Debian by Debian users. For an example check the bugs reported in the BTS, and, yes, I've been also slow in fixing bugs there.
If you would be willing to help co-maintain a set of packages for Debian we could probably review your packages and have them available in the unstable and, eventually, in the stable distribution.
Certification is not a question of technical merit, it's also based on a lot of paperwork as well as a lot of money that needs to be "given" to a certification laboratory that validates all that paperwork
I've been pushing for a Debian CC certification myself, but it's not probable that this will come to pass unless it's sponsored.
You do have a Debian-derived product that is currently CC certified EAL4: Stonesoft's Stonegate (security target available at NIST's NIAP, the Common Criteria site seems to have been discontinued unfortunately). It is certified versus a firewall-specific Protection Profile, though, so it should not be used as a comparison metric against others that are certified against an operating system PP.
As mentioned in order comment Wichert Akkerman has setup a page explaining the current situation at http://www.wiggy.net/debian/
Notice that you will not find a note in the www.debian.org web server since until all the servers are being restored and are back online a public note (giving more details than the previous announcement) is being postponed. Also, the infraestructure used to build up the web site (english + all the translations) is part of the compromised servers.
The problem with the old TAMU version is that it was getting as out of date as SATAN was. It still is a good framework and has lots of room for improvement.
Also, it's the only tool of that time that is completely free. SATAN, COPS and ISS are either outdated or no longer free and new replacements have appeared for some of them (Nessus).
Tiger it is not a logchecker, nor it focused in integrity analysis. It does "the other stuff", it checks the system configuration and status.
Just read the manpage (and it's not fully up to date, i.e, it does not include the new checks). I bet you will be surprised. For example, it has a module that can determine which network servers you are running are using deleted files (because you patched the libraries through a package upgrade but the server was not restarted).
As for system security checks that Tiger provides that others do not you can read this (short) comparison.