Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
On 10/02/02, Lazarus Long wrote: On Sat, Jan 26, 2002 at 12:25:08PM +, Matthew Vernon wrote: Lazarus Long writes: Introduces security hole by divulging too much information to an attacker about the underlying system. The rationale behind this, is that there are many instances where it is useful for a network admin to know whether the sshd on a particular machine is secure or not Of course it is useful, Matthew, but that admin can do so, safely *logged in to* the machine in question, with the 'dpkg -l ssh' command I mentioned above. There is no need to advertise any vulnerabilities to those *outside* the machine. So if you have more then 50 machines in your network to administrate which run debian, you will login into every machine typing always your passphrase or the password just to run dpkg -l ssh to find out which version of ssh is used on that machine? And ssh-agent is not a good solution here, because it might expose your passphrase or other important information. - in stable, our version of sshd gives out a version string identical to a very insecure upstream version, yet is patched. How is this in any way relevant? How shall an administrator from knowing just the version number of the sshd itself be sure that this machine runs a patched and therefor secure version of the client without having to use the procedure I described above? I reject the security-by-obscurity claim you make - attackers don't Again, security-by-obscurity (which you seem to be parroting from another misinformed individual in this thread) is properly used to refer to *source code* availability, for peer review within the crypto community, not the specifics of any given machine's implementation. No, I don't agree with you here. Security-by-obscurity doesn't only refer to those cases, but also to other problems. It's a common used term to describe a situation where one achieves security by witholding information. (I refer you to my comment about post your root password and IP address if you think obscurity is irrelevant.) And that helps you how much if the machine wants a passphrase or an otp-key? I will include a quote at the end of this message from an appropriate source, if this will help to further understanding. care what OS you're running often, they just try everything on the network. Furthermore, it is trivial [queso(8)] to find out what OS Running queso against four different machines here returns either the erroneous * Standard: Solaris 2.x, Linux 2.1.???, MacOS or else *- Not Listen, try another port. None of those machines run any of the operating systems queso reported. And when then don't you start reading either queso -h or man queso to find out how to use it? Besides, if version x of upstream has bug y, and Debian package x-n of upstream version x hasn't, then what do you care if someone tries the exploit on you? And what about the opposite scenario? Debian has very recently taken months to close a known security hole, without telling the end-users, And how many security holes have been fixed in a timely manner by Debian? Picking out one bad example is easy, but you need to look at in relation to the many security fixes that have been released much sooner. Unless you can produce a more convincing argument, I intend to close this bug. Since my own words seem to have been inadequate in the past, I'll paste here a fair-use excerpt from the most recent book from a widely-known and highly-regarded authority in the computer security (and crypto) field, whom I hope you will recognize. This excerpt is taken from p. 371f of Bruce Schneier's _Secrets and Lies, Digital Security in a Networked World_ (Wiley and Sons, 2000) One of the strengths an attacker has is knowledge of the terrain. Just as an army doesn't broadcast the location of its tanks, anti-aircraft missiles, and battalions to the enemy, there's no reason to broadcast your network topology to everyone that asks. Too many computers respond to any query with their operating system and version number; there's no reason to give out this information. Much better would be a login screen that reads: Warning: Proprietary Computer. Use of this system constitutes consent to security monitoring. All user activity is logged, including the hostname and IP address. Let the attackers wonder if you can trace them. ... An attacker shouldn't know what types of equipment are running where, what protocols are allowed under what conditions, what ports are open under what conditions. I am amazed by the number of servers, applications and protocols that announce themselves to the world: Hello! I am randomservice V2.05.Many hacking (sic) tools scan for particular versions of software running on particular machines ... known to have particular vulnerabilities. If networks
Re: Bug#130876: ssh: -5 discloses too much infomation to an attacker, security
On 10/02/02, Lazarus Long wrote: On Sat, Jan 26, 2002 at 12:25:08PM +, Matthew Vernon wrote: Lazarus Long writes: Introduces security hole by divulging too much information to an attacker about the underlying system. The rationale behind this, is that there are many instances where it is useful for a network admin to know whether the sshd on a particular machine is secure or not Of course it is useful, Matthew, but that admin can do so, safely *logged in to* the machine in question, with the 'dpkg -l ssh' command I mentioned above. There is no need to advertise any vulnerabilities to those *outside* the machine. So if you have more then 50 machines in your network to administrate which run debian, you will login into every machine typing always your passphrase or the password just to run dpkg -l ssh to find out which version of ssh is used on that machine? And ssh-agent is not a good solution here, because it might expose your passphrase or other important information. - in stable, our version of sshd gives out a version string identical to a very insecure upstream version, yet is patched. How is this in any way relevant? How shall an administrator from knowing just the version number of the sshd itself be sure that this machine runs a patched and therefor secure version of the client without having to use the procedure I described above? I reject the security-by-obscurity claim you make - attackers don't Again, security-by-obscurity (which you seem to be parroting from another misinformed individual in this thread) is properly used to refer to *source code* availability, for peer review within the crypto community, not the specifics of any given machine's implementation. No, I don't agree with you here. Security-by-obscurity doesn't only refer to those cases, but also to other problems. It's a common used term to describe a situation where one achieves security by witholding information. (I refer you to my comment about post your root password and IP address if you think obscurity is irrelevant.) And that helps you how much if the machine wants a passphrase or an otp-key? I will include a quote at the end of this message from an appropriate source, if this will help to further understanding. care what OS you're running often, they just try everything on the network. Furthermore, it is trivial [queso(8)] to find out what OS Running queso against four different machines here returns either the erroneous * Standard: Solaris 2.x, Linux 2.1.???, MacOS or else *- Not Listen, try another port. None of those machines run any of the operating systems queso reported. And when then don't you start reading either queso -h or man queso to find out how to use it? Besides, if version x of upstream has bug y, and Debian package x-n of upstream version x hasn't, then what do you care if someone tries the exploit on you? And what about the opposite scenario? Debian has very recently taken months to close a known security hole, without telling the end-users, And how many security holes have been fixed in a timely manner by Debian? Picking out one bad example is easy, but you need to look at in relation to the many security fixes that have been released much sooner. Unless you can produce a more convincing argument, I intend to close this bug. Since my own words seem to have been inadequate in the past, I'll paste here a fair-use excerpt from the most recent book from a widely-known and highly-regarded authority in the computer security (and crypto) field, whom I hope you will recognize. This excerpt is taken from p. 371f of Bruce Schneier's _Secrets and Lies, Digital Security in a Networked World_ (Wiley and Sons, 2000) One of the strengths an attacker has is knowledge of the terrain. Just as an army doesn't broadcast the location of its tanks, anti-aircraft missiles, and battalions to the enemy, there's no reason to broadcast your network topology to everyone that asks. Too many computers respond to any query with their operating system and version number; there's no reason to give out this information. Much better would be a login screen that reads: Warning: Proprietary Computer. Use of this system constitutes consent to security monitoring. All user activity is logged, including the hostname and IP address. Let the attackers wonder if you can trace them. ... An attacker shouldn't know what types of equipment are running where, what protocols are allowed under what conditions, what ports are open under what conditions. I am amazed by the number of servers, applications and protocols that announce themselves to the world: Hello! I am randomservice V2.05.Many hacking (sic) tools scan for particular versions of software running on particular machines ... known to have particular vulnerabilities. If networks are
Re: Don't panic (ssh)
On 14/01/02, [EMAIL PROTECTED] wrote: AFAIK, all SSH1 connections are vulnerable to the CRC32 attack. Thus you need to use SSH2 protocol. OpenSSH supports SSH2. You need different keys though, as SSH2 so far does not support RSA keypairs and needs DSA keys. OpenSSH supports both, RSA and DSA keys for SSH protocol version 2. Please read the manpage for ssh and look for the paragraph called SSH protocol version 2 where this is explained. But you are right about the CRC32 attack. The crc32 compensation attack is a vulnerability in the SSH protocol version 1. An analysis of this exploit can be found at: http://staff.washington.edu/dittrich/misc/ssh-analysis.txt And here's an excerpt from a mail (MID: [EMAIL PROTECTED]) about the rules, which clients or servers are vulnerable. The comments are from Markus Friedl, one of the openssh authors: , | the rules are simpler: | | 1) protocol 2 only | | all | SSH-2.0-* | are not affected, since no protocol v1 is iisnvolved. | | 2) protocol 1 und 2 support | | since | SSH-1.99-* | supports both protocol versions, it gets more difficult. | for the commercial server, you never know the version | of the server that will be called for the fallback, | you have to assume that all | SSH-1.99-[23]* | are affected, and | SSH-1.99-OpenSSH[-_].x.y | are affected for versions x.y 2.3 | | 3) protocol 1 only | SSH-1.5-OpenSSH[-_].x.y | is affected versions x.y 2.3 | | and the commercial versions. | | SSH-1.5-1.2.2[456789] | SSH-1.5-1.2.3[01] | | so: ` Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 msg05233/pgp0.pgp Description: PGP signature
Re: Don't panic (ssh)
On 14/01/02, [EMAIL PROTECTED] wrote: AFAIK, all SSH1 connections are vulnerable to the CRC32 attack. Thus you need to use SSH2 protocol. OpenSSH supports SSH2. You need different keys though, as SSH2 so far does not support RSA keypairs and needs DSA keys. OpenSSH supports both, RSA and DSA keys for SSH protocol version 2. Please read the manpage for ssh and look for the paragraph called SSH protocol version 2 where this is explained. But you are right about the CRC32 attack. The crc32 compensation attack is a vulnerability in the SSH protocol version 1. An analysis of this exploit can be found at: http://staff.washington.edu/dittrich/misc/ssh-analysis.txt And here's an excerpt from a mail (MID: [EMAIL PROTECTED]) about the rules, which clients or servers are vulnerable. The comments are from Markus Friedl, one of the openssh authors: , | the rules are simpler: | | 1) protocol 2 only | | all | SSH-2.0-* | are not affected, since no protocol v1 is iisnvolved. | | 2) protocol 1 und 2 support | | since | SSH-1.99-* | supports both protocol versions, it gets more difficult. | for the commercial server, you never know the version | of the server that will be called for the fallback, | you have to assume that all | SSH-1.99-[23]* | are affected, and | SSH-1.99-OpenSSH[-_].x.y | are affected for versions x.y 2.3 | | 3) protocol 1 only | SSH-1.5-OpenSSH[-_].x.y | is affected versions x.y 2.3 | | and the commercial versions. | | SSH-1.5-1.2.2[456789] | SSH-1.5-1.2.3[01] | | so: ` Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp6qKOImSObb.pgp Description: PGP signature
Re: Secure wu-ftpd for Testing?
On 30/11/01, David Ehle wrote: Is the wu-ftpd in testing secure? It seems to be 2.6.1 a stinker. Not so far. But calling a software where the source and the fix are available, so that you can build a fixed version on your own is inappropriate. Especially if you are using Win98 and Netscape, both closed source products, for mailing. Do you also call mail both companies calling their software a stinker and asking them directly for fixed versions? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 msg04542/pgp0.pgp Description: PGP signature
Re: Secure wu-ftpd for Testing?
On 30/11/01, David Ehle wrote: Is the wu-ftpd in testing secure? It seems to be 2.6.1 a stinker. Not so far. But calling a software where the source and the fix are available, so that you can build a fixed version on your own is inappropriate. Especially if you are using Win98 and Netscape, both closed source products, for mailing. Do you also call mail both companies calling their software a stinker and asking them directly for fixed versions? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpGLP5tbcbdB.pgp Description: PGP signature
Re: [OT] resctrict ssh to localnet for some users but not for others.
On 27/11/01, martin f krafft wrote: * op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]: I specify the users in /ets/ssh/sshd_config who are allowed to connect via ssh. But I'd like some more control. I'd like to control which subnets user x can connect from. Some should be allowed to connect from anywhere but some should only be able to conect from the local network. nope, this isn't possible with the current sshd. an interesting feature though... you could write a custom shell that checks the IP after login and only spawns a shell when it's from an OK subnet... | AllowUsers | This keyword can be followed by a list of user names, separated | by spaces. If specified, login is allowed only for users names | that match one of the patterns. `*' and `'? can be used as | wildcards in the patterns. Only user names are valid; a numeri | cal user ID is not recognized. By default login is allowed | regardless of the user name. If the pattern takes the form | USER@HOST then USER and HOST are separately checked, restricting | logins to particular users from particular hosts. Well, this option for the sshd is at least available in the latest cvs of OpenSSH and is as far as I remember also availale in in the latest official release (3.0p1). So at least it's possible to restrict a user to come from a certain host. But I'm thinking it won't work with Subnets or Host-Patterns so far. And I'm not really sure if it's that easy to extend the functionality of this option to subnets. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 msg04400/pgp0.pgp Description: PGP signature
Re: [OT] resctrict ssh to localnet for some users but not for others.
On 27/11/01, martin f krafft wrote: * op [EMAIL PROTECTED] [2001.11.27 10:23:57+0100]: I specify the users in /ets/ssh/sshd_config who are allowed to connect via ssh. But I'd like some more control. I'd like to control which subnets user x can connect from. Some should be allowed to connect from anywhere but some should only be able to conect from the local network. nope, this isn't possible with the current sshd. an interesting feature though... you could write a custom shell that checks the IP after login and only spawns a shell when it's from an OK subnet... | AllowUsers | This keyword can be followed by a list of user names, separated | by spaces. If specified, login is allowed only for users names | that match one of the patterns. `*' and `'? can be used as | wildcards in the patterns. Only user names are valid; a numeri | cal user ID is not recognized. By default login is allowed | regardless of the user name. If the pattern takes the form | [EMAIL PROTECTED] then USER and HOST are separately checked, restricting | logins to particular users from particular hosts. Well, this option for the sshd is at least available in the latest cvs of OpenSSH and is as far as I remember also availale in in the latest official release (3.0p1). So at least it's possible to restrict a user to come from a certain host. But I'm thinking it won't work with Subnets or Host-Patterns so far. And I'm not really sure if it's that easy to extend the functionality of this option to subnets. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpH5n2rFix5i.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On 29/10/01, Emmanuel Lacour wrote: On Mon, Oct 29, 2001 at 09:48:00AM +1300, Stephen Andrew wrote: What about a package ssh-chroot in debian? I think the pam module is more interesting as it can be aplied to other thinks, but I tried it and was unable to make it working (I'm not a pam master!!). What do you exactly mean unable to make it working? Did you change /etc/pam.d/ssh(d?) to contain a line like this: |session required /lib/security/pam_chroot.so debug onerr=fail If yes, did you check logfiles for any hints? If yes, what kind of error message did you get? Does ssh -v show any helpful info? I haven't used that pam-module so far, but I don't think that it will be so difficult to get it working. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQUXya11HR8.pgp Description: PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On 26/10/01, Javier Fernández-Sanguino Peña wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: [off-topic?] Chrooting ssh/telnet users?
On 26/10/01, Javier Fernández-Sanguino Peña wrote: The problem is, how can an admin restrict remote access from a given user (through telnet and/or sshd) in order to limit his moves inside the operating system. [...] AFAIK, pam only allows to limit some user accesses (cores, memory limits..) not users movement in the OS That's a wrong assumption. At least RedHat contains a pam_chroot.so module which can be used in connection with the latest ssh to limit a user into a chroot. I'm just wondering if that module is packaged already for debian or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTy6jzAzuz3.pgp Description: PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On 23/10/01, Michael Robinson wrote: On Tue, Oct 23, 2001 at 09:55:04AM +0200, Christian Kurz wrote: Do you know how difficult and time-consuming it really is to do a manual source code audit? Also the available programs for source code audits can only give you hints which parts of a program might be suspicious, but you still would have to verify everything by hand to be really sure. FreeBSD does it for their ports tree. In fact, this has been a matter of Does what? Just look for some suspicous functions or code-fragments or do a full audiit for the whole source? Yes, source-code audits are time-consuming. Time-consuming is different from not possible, however. Why the hell do you try to interpret into my previous e-Mail that I'm saying they would be not possible? Maybe you need to read it again, but it clearly states, that a full audit of the code for one package takes an enourmous account of time and that you also need quite lots of knowledge for such a task. And especially since we talked about having an audit _before_ having the package be included as a debian package into the archive, a full audit of all new packages would decrease the number of packages entering the archive and also take a very long time, since everyone here is a volunteer. Also you still have the problem left with about 8000 packages being already included in debian and having mostly never had a full audit. So for really auditing debian and ensuring that every malicous code is found and either removed or fixed, you would have to drop all packages and start with for example init and audit it. After that once if full audit, you can move on to for example login and so on, until you audited every package from the current number of packages completely. Until such an effort has been made to ensure, that there's currently no malicous code included in debian, a full audit of new packages would only be the tip of an iceberg. The alternative is the ostrich method of security management. What's that kind of method? I never heared about that name. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On 23/10/01, Michael Robinson wrote: On Tue, Oct 23, 2001 at 09:55:04AM +0200, Christian Kurz wrote: Do you know how difficult and time-consuming it really is to do a manual source code audit? Also the available programs for source code audits can only give you hints which parts of a program might be suspicious, but you still would have to verify everything by hand to be really sure. FreeBSD does it for their ports tree. In fact, this has been a matter of Does what? Just look for some suspicous functions or code-fragments or do a full audiit for the whole source? Yes, source-code audits are time-consuming. Time-consuming is different from not possible, however. Why the hell do you try to interpret into my previous e-Mail that I'm saying they would be not possible? Maybe you need to read it again, but it clearly states, that a full audit of the code for one package takes an enourmous account of time and that you also need quite lots of knowledge for such a task. And especially since we talked about having an audit _before_ having the package be included as a debian package into the archive, a full audit of all new packages would decrease the number of packages entering the archive and also take a very long time, since everyone here is a volunteer. Also you still have the problem left with about 8000 packages being already included in debian and having mostly never had a full audit. So for really auditing debian and ensuring that every malicous code is found and either removed or fixed, you would have to drop all packages and start with for example init and audit it. After that once if full audit, you can move on to for example login and so on, until you audited every package from the current number of packages completely. Until such an effort has been made to ensure, that there's currently no malicous code included in debian, a full audit of new packages would only be the tip of an iceberg. The alternative is the ostrich method of security management. What's that kind of method? I never heared about that name. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp0U8rBFQHYh.pgp Description: PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On 23/10/01, Javier Fernández-Sanguino Peña wrote: On Mon, Oct 22, 2001 at 09:31:38PM +0200, Christian Kurz wrote: What does security policies for building a debian package exactly have to do with securing a debian box? System administrator reading this document will be interested in tips and howtos on improving the security on the boxes, that he administrates. He's certainly not interested in knowing how to securely build a debian package. The point is. I'm starting to think on changing the document title to something on the lines of Debian Security Manual and go a little deeper into Debian security stuff (advisories, the security team, etc..) Well, advisories still would fit into a Securing Debian Manual because they are an important part of increase the security of the system someone is responsible for. I don't know what exactly you want to write about the security team, but maybe it would also fit. Information about securing the build system and how to securely build Debian packages should be an extra document for interested developers in my humble opinion. That will soon be discovered and I would say those maintainer is facing definetely problems. Migh I remember you that we are not (IIRC) doing a source code Do you know how difficult and time-consuming it really is to do a manual source code audit? Also the available programs for source code audits can only give you hints which parts of a program might be suspicious, but you still would have to verify everything by hand to be really sure. audit of packages. That soon is supposing that his package is widely used and the mischief promptly discovered. I don't think so, because any mischief that isn't triggered by some obscure situation or configuration, will be very fast discovered. And also the package doesn't need to be widely used, since we have quite some people following unstable and new packages closely, which would then report bugs. lintian does check many issues regarding policy, but it does not test potential security problems. Which is correct, since lintian is only written for checking policy compliance. If you want a tool checking for security problems, you should write another new tool for this purpose. Not exactly right, policy does talk about security related issues, and lintian should check them. For example: 11.9. Permissions and owners The rules in this section are guidelines for general use. If necessary you may deviate from the details below. However, if you do so you must make sure that what is done is *secure* and you should try to be as consistent as possible with the rest of the system. (emphasis is mine) Did you read just this small paragraph or the whole section 11.9 from the policy? If you have read it, then you should have noticed that it clearly talks about useful permission for certain cases, which don't open security holes. It absolutely is not talking about how to change permissions and owners to have a really secure system. That would involve for example also checking for setuid,setgid files or world-writable directories for example. So. Since we do not source code audits of incoming packages and this kind of issues are not detected automatically... does this leave the Debian distribution open to attack if a developer box gets hacked into? No, new packages are not automatically becoming available for everyone and will be reviewed before. So this doesn't leave the distribution open for that kind of attacks you imagine. So, then, for the record (i.e. the manual) what kind of reviews are made for incoming/new packages (besides lintian checks). I do know that the archive maintainers do this stuff, could someone introduce me to what reviews (security-wise) are made? Please ask the ftp-masters about this issue, since they are the best authority you can ask for getting the necessary information about this. No, because that's not the purpose of lintian. Write either a new tool for that purpose or leave it. But be aware that it's very difficult to detect all kinds of possible attacks or trojans that one could create. I agree. However, with the Debian package format becoming increasingly popular, it does have some flaws (IMHO, I might get smacked for saying this :) which might be used to introduce simple troyans. I would say, that not only the Debian package format has it's shortcomings, but that the same applies for the rpm format also. There's no format available which doesn't have any short-coming. [0] Regardless of the package contents (which might be a troyan by itself) having the post-pre-install-remove script as a root user with an unrestricted shell (or perl, or whatever) could turn into potential problems on the long term. You know that a restricted shell, for example rbash, is not going to stop someone from breaking out
Re: Does Debian need to enforce a better Security policy for packages?
On 23/10/01, Javier Fernández-Sanguino Peña wrote: On Mon, Oct 22, 2001 at 09:31:38PM +0200, Christian Kurz wrote: What does security policies for building a debian package exactly have to do with securing a debian box? System administrator reading this document will be interested in tips and howtos on improving the security on the boxes, that he administrates. He's certainly not interested in knowing how to securely build a debian package. The point is. I'm starting to think on changing the document title to something on the lines of Debian Security Manual and go a little deeper into Debian security stuff (advisories, the security team, etc..) Well, advisories still would fit into a Securing Debian Manual because they are an important part of increase the security of the system someone is responsible for. I don't know what exactly you want to write about the security team, but maybe it would also fit. Information about securing the build system and how to securely build Debian packages should be an extra document for interested developers in my humble opinion. That will soon be discovered and I would say those maintainer is facing definetely problems. Migh I remember you that we are not (IIRC) doing a source code Do you know how difficult and time-consuming it really is to do a manual source code audit? Also the available programs for source code audits can only give you hints which parts of a program might be suspicious, but you still would have to verify everything by hand to be really sure. audit of packages. That soon is supposing that his package is widely used and the mischief promptly discovered. I don't think so, because any mischief that isn't triggered by some obscure situation or configuration, will be very fast discovered. And also the package doesn't need to be widely used, since we have quite some people following unstable and new packages closely, which would then report bugs. lintian does check many issues regarding policy, but it does not test potential security problems. Which is correct, since lintian is only written for checking policy compliance. If you want a tool checking for security problems, you should write another new tool for this purpose. Not exactly right, policy does talk about security related issues, and lintian should check them. For example: 11.9. Permissions and owners The rules in this section are guidelines for general use. If necessary you may deviate from the details below. However, if you do so you must make sure that what is done is *secure* and you should try to be as consistent as possible with the rest of the system. (emphasis is mine) Did you read just this small paragraph or the whole section 11.9 from the policy? If you have read it, then you should have noticed that it clearly talks about useful permission for certain cases, which don't open security holes. It absolutely is not talking about how to change permissions and owners to have a really secure system. That would involve for example also checking for setuid,setgid files or world-writable directories for example. So. Since we do not source code audits of incoming packages and this kind of issues are not detected automatically... does this leave the Debian distribution open to attack if a developer box gets hacked into? No, new packages are not automatically becoming available for everyone and will be reviewed before. So this doesn't leave the distribution open for that kind of attacks you imagine. So, then, for the record (i.e. the manual) what kind of reviews are made for incoming/new packages (besides lintian checks). I do know that the archive maintainers do this stuff, could someone introduce me to what reviews (security-wise) are made? Please ask the ftp-masters about this issue, since they are the best authority you can ask for getting the necessary information about this. No, because that's not the purpose of lintian. Write either a new tool for that purpose or leave it. But be aware that it's very difficult to detect all kinds of possible attacks or trojans that one could create. I agree. However, with the Debian package format becoming increasingly popular, it does have some flaws (IMHO, I might get smacked for saying this :) which might be used to introduce simple troyans. I would say, that not only the Debian package format has it's shortcomings, but that the same applies for the rpm format also. There's no format available which doesn't have any short-coming. [0] Regardless of the package contents (which might be a troyan by itself) having the post-pre-install-remove script as a root user with an unrestricted shell (or perl, or whatever) could turn into potential problems on the long term. You know that a restricted shell, for example rbash, is not going to stop someone from breaking out
Re: Does Debian need to enforce a better Security policy for packages?
On 22/10/01, Javier Fernández-Sanguino Peña wrote: I am looking into the security policies outlined for package building, in order to include some notes regarding them in the section How does Debian handle security in the Securing Debian Manual (http://www.debian.org/doc/ddp) What does security policies for building a debian package exactly have to do with securing a debian box? System administrator reading this document will be interested in tips and howtos on improving the security on the boxes, that he administrates. He's certainly not interested in knowing how to securely build a debian package. For example, I have been recently asked if a maintainer can do whatever he wishes in a package. Can he? Sure, we have policies, but what if we have a debian developer distributing a trojan in a package. IMHO That will soon be discovered and I would say those maintainer is facing definetely problems. lintian does check many issues regarding policy, but it does not test potential security problems. Which is correct, since lintian is only written for checking policy compliance. If you want a tool checking for security problems, you should write another new tool for this purpose. I just made an empty package with dh_make with only a postinst having 'rm -rf /'. Lintian says: $ lintian test-rm*deb E: test-rm: description-is-dh_make-template E: test-rm: helper-templates-in-copyright W: test-rm: readme-debian-is-debmake-template W: test-rm: unknown-section unknown So. Since we do not source code audits of incoming packages and this kind of issues are not detected automatically... does this leave the Debian distribution open to attack if a developer box gets hacked into? No, new packages are not automatically becoming available for everyone and will be reviewed before. So this doesn't leave the distribution open for that kind of attacks you imagine. Should we improve lintian in order to yell if some (destructive) action is taken upon installation/de-installation? Should we further limit the kind No, because that's not the purpose of lintian. Write either a new tool for that purpose or leave it. But be aware that it's very difficult to detect all kinds of possible attacks or trojans that one could create. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On 22/10/01, Javier Fernández-Sanguino Peña wrote: I am looking into the security policies outlined for package building, in order to include some notes regarding them in the section How does Debian handle security in the Securing Debian Manual (http://www.debian.org/doc/ddp) What does security policies for building a debian package exactly have to do with securing a debian box? System administrator reading this document will be interested in tips and howtos on improving the security on the boxes, that he administrates. He's certainly not interested in knowing how to securely build a debian package. For example, I have been recently asked if a maintainer can do whatever he wishes in a package. Can he? Sure, we have policies, but what if we have a debian developer distributing a trojan in a package. IMHO That will soon be discovered and I would say those maintainer is facing definetely problems. lintian does check many issues regarding policy, but it does not test potential security problems. Which is correct, since lintian is only written for checking policy compliance. If you want a tool checking for security problems, you should write another new tool for this purpose. I just made an empty package with dh_make with only a postinst having 'rm -rf /'. Lintian says: $ lintian test-rm*deb E: test-rm: description-is-dh_make-template E: test-rm: helper-templates-in-copyright W: test-rm: readme-debian-is-debmake-template W: test-rm: unknown-section unknown So. Since we do not source code audits of incoming packages and this kind of issues are not detected automatically... does this leave the Debian distribution open to attack if a developer box gets hacked into? No, new packages are not automatically becoming available for everyone and will be reviewed before. So this doesn't leave the distribution open for that kind of attacks you imagine. Should we improve lintian in order to yell if some (destructive) action is taken upon installation/de-installation? Should we further limit the kind No, because that's not the purpose of lintian. Write either a new tool for that purpose or leave it. But be aware that it's very difficult to detect all kinds of possible attacks or trojans that one could create. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpRqfg4yvcfm.pgp Description: PGP signature
Re: Is ident secure?
On 01-08-31 Martin F Krafft wrote: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? honest question: whose business is the name of a user who initiated a connection??? It can be some sort of help if you have a system with lots of users and complainments about one. Some admins may be able to send you the logged ident information and if you then can trust you ident server, you get a nice hint to the user, who is responsible. But this depends heavily on the fact, if you can be sure that your ident server hasn't been modified/replaced. identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and Would you mind explaining that statement? names, but other than that, don't worry about it. ident is a hacker's friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. No, that's a wrong statement. Ident doesn't necessarily tell you anything about the user. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Is ident secure?
On 01-08-30 Brian P. Flaherty wrote: I have had a lot of problems running non-Debian software when I disable ident. It seems like the licensing daemons expect to find What the hell is a licensing daemon? And which package contains this software in debian? May I suggest that you first start reading the RfC about Ident Protocol before you make wrong statements? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Is ident secure?
On 01-08-31 Martin F Krafft wrote: also sprach Christian Kurz (on Fri, 31 Aug 2001 10:12:31AM +0200): honest question: whose business is the name of a user who initiated a connection??? It can be some sort of help if you have a system with lots of users and complainments about one. Some admins may be able to send you the logged ident information and if you then can trust you ident server, you get a nice hint to the user, who is responsible. But this depends heavily on the fact, if you can be sure that your ident server hasn't been modified/replaced. process accounting. process accounting. Would you care to explain that a bit more and especially compare it with ident protocol (advantages and disadvantages)? identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and Would you mind explaining that statement? it's in my other post. ident is an easy way to establish whether e.g. named is running as root so as to properly target attacks. It's absolutely not. This heavily depends on the setup of your ident daemon. names, but other than that, don't worry about it. ident is a hacker's friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. No, that's a wrong statement. Ident doesn't necessarily tell you anything about the user. it tells you the uid. for root, that's 'root' and that's pretty damn sensitive information right there... Argh, wrong again. Would you now mind reading the RfC describing the Ident Protocol? It's possible to run ident daemons, which don't tell you an name or uid. Why don't you inform yourself before making wrong claims? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Is ident secure?
On 01-08-31 Martin F Krafft wrote: On Thu, Aug 30, 2001 at 11:14:33PM -0300, Alisson Sellaro wrote: I was checking my firewall logs and have detected lots of TCP/113 dropped packets. Checking /etc/services I realized it was ident traffic. What do you think about such service? Should I let it blocked or should I allow it without further security exposure? honest question: whose business is the name of a user who initiated a connection??? It can be some sort of help if you have a system with lots of users and complainments about one. Some admins may be able to send you the logged ident information and if you then can trust you ident server, you get a nice hint to the user, who is responsible. But this depends heavily on the fact, if you can be sure that your ident server hasn't been modified/replaced. identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and Would you mind explaining that statement? names, but other than that, don't worry about it. ident is a hacker's friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. No, that's a wrong statement. Ident doesn't necessarily tell you anything about the user. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpUdLs0IYSLN.pgp Description: PGP signature
Re: Is ident secure?
On 01-08-31 Martin F Krafft wrote: also sprach Christian Kurz (on Fri, 31 Aug 2001 10:12:31AM +0200): honest question: whose business is the name of a user who initiated a connection??? It can be some sort of help if you have a system with lots of users and complainments about one. Some admins may be able to send you the logged ident information and if you then can trust you ident server, you get a nice hint to the user, who is responsible. But this depends heavily on the fact, if you can be sure that your ident server hasn't been modified/replaced. process accounting. process accounting. Would you care to explain that a bit more and especially compare it with ident protocol (advantages and disadvantages)? identd is a horrible concept and elicits shrieks among the security conscious. i do understand that you need it for this and Would you mind explaining that statement? it's in my other post. ident is an easy way to establish whether e.g. named is running as root so as to properly target attacks. It's absolutely not. This heavily depends on the setup of your ident daemon. names, but other than that, don't worry about it. ident is a hacker's friend, not only because nmap can tell everyone who is running the services behind your open ports. you don't want that. No, that's a wrong statement. Ident doesn't necessarily tell you anything about the user. it tells you the uid. for root, that's 'root' and that's pretty damn sensitive information right there... Argh, wrong again. Would you now mind reading the RfC describing the Ident Protocol? It's possible to run ident daemons, which don't tell you an name or uid. Why don't you inform yourself before making wrong claims? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpNsWgyLThex.pgp Description: PGP signature
Re: New security packages available
On 01-08-26 Javier Fernández-Sanguino Peña wrote: - New integrity checkers (currently tripwire and aide were available): integrit and samhain You know that integrit is already packaged for debian? Package: integrit Priority: optional Section: admin Installed-Size: 509 Maintainer: Andras Bali [EMAIL PROTECTED] Architecture: i386 Version: 2.02.02beta-1 Depends: libc6 (= 2.2.3-7) Recommends: debconf Filename: pool/main/i/integrit/integrit_2.02.02beta-1_i386.deb Size: 226914 MD5sum: e6444adbaa080f008acbac82ab9993dd Description: A file integrity verification program like tripwire Integrit helps you determine whether an intruder has modified your system. Without the use of integrit, a sysadmin wouldn't know if the programs used for investigating the system are trojan horses or not. Integrit works by creating a database that is a snapshot of the most essential parts of the system. You put the database somewhere safe, and then later you can use it to make sure that noone has made any illicit modifications to your system. . Integrit's key features are the small memory footprint, the design with unattended use in mind, intuitive cascading rulesets for the paths listed in the configuration file, the possibility of XML or human-readable output and simultaneous check and update. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: New security packages available
On 01-08-26 Javier Fernández-Sanguino Peña wrote: - New integrity checkers (currently tripwire and aide were available): integrit and samhain You know that integrit is already packaged for debian? Package: integrit Priority: optional Section: admin Installed-Size: 509 Maintainer: Andras Bali [EMAIL PROTECTED] Architecture: i386 Version: 2.02.02beta-1 Depends: libc6 (= 2.2.3-7) Recommends: debconf Filename: pool/main/i/integrit/integrit_2.02.02beta-1_i386.deb Size: 226914 MD5sum: e6444adbaa080f008acbac82ab9993dd Description: A file integrity verification program like tripwire Integrit helps you determine whether an intruder has modified your system. Without the use of integrit, a sysadmin wouldn't know if the programs used for investigating the system are trojan horses or not. Integrit works by creating a database that is a snapshot of the most essential parts of the system. You put the database somewhere safe, and then later you can use it to make sure that noone has made any illicit modifications to your system. . Integrit's key features are the small memory footprint, the design with unattended use in mind, intuitive cascading rulesets for the paths listed in the configuration file, the possibility of XML or human-readable output and simultaneous check and update. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp2dCWqgw49W.pgp Description: PGP signature
Re: Mutt and inline gpg
On 01-08-09 Martin Domig wrote: On Thu, Aug 09, 2001 at 08:03:15PM +1000, Matt Hope wrote: [...] : When my friends (2 differnt ones, one of which is planning to switch : to mutt) get the mails, they get it in an attachment, have to save it : and decode it manually (apparently kmail is expecting inline messages). : Obviously, mutt/mutt and kmail/kmail messages are working perfectly. `- I've seen a few procmail recipes around which remedy this. [...] I am using the same procmail filter and can say that it works perfectly for incoming pgp/gpg mails. However, this does not solve the problem with other mail clients that want to have inline PGP messages, and those are many. Is there a way to make mutt send inline PGP messages instead of the MIME attachment form? Is it so difficult to look first into the fine manual of mutt or call man muttrc and look therefor an answer before asking the list? If you would have done one of the first know actions, you would have found the option pgp_create_traditional. That option might help you very much, but instead I would suggest that the other MUA's get fixed. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Mutt and inline gpg
On 01-08-09 Martin Domig wrote: On Thu, Aug 09, 2001 at 08:03:15PM +1000, Matt Hope wrote: [...] : When my friends (2 differnt ones, one of which is planning to switch : to mutt) get the mails, they get it in an attachment, have to save it : and decode it manually (apparently kmail is expecting inline messages). : Obviously, mutt/mutt and kmail/kmail messages are working perfectly. `- I've seen a few procmail recipes around which remedy this. [...] I am using the same procmail filter and can say that it works perfectly for incoming pgp/gpg mails. However, this does not solve the problem with other mail clients that want to have inline PGP messages, and those are many. Is there a way to make mutt send inline PGP messages instead of the MIME attachment form? Is it so difficult to look first into the fine manual of mutt or call man muttrc and look therefor an answer before asking the list? If you would have done one of the first know actions, you would have found the option pgp_create_traditional. That option might help you very much, but instead I would suggest that the other MUA's get fixed. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpPc25ghRtkT.pgp Description: PGP signature
Re: pop3
On 01-07-30 Andrew Sione Taumoefolau wrote: I've you are using vim use: set textwidth=72 in your .vimrc to wrap te lines to a max of 72 char. Probably better not to do it that way, unless you're okay with Vim wrapping ALL documents you edit with it at 72 characters. I've got a line in my .muttrc that goes something like this: set editor = vim -c 'set tw=72' ...which does the trick, but I think there's a cleaner way to do it. An easier way would be to use the autocmd feature of vim. I use it for example this way: |autocmd BufNewFile,BufReadPost reportbug*,mutt-* set textwidth=72 With the help of this autocommand vim will always do a wrap line to 72 characters maximum if I write a mail or a new bug report. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpvEd0topXoX.pgp Description: PGP signature
Re: gnupg problem
On 01-06-18 Thomas Bushnell, BSG wrote: In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main. Would you please check the next time either your box running unstable or packages.debian.org? If you had done this before, you would have noticed, that mailcrypt from stable also offered an interface to PGP (pgp-i, pgp-us and pgp5i are the matching debian packages, which have been in non-free and maybe still are there). But this has been changed since quite some time, so that that mailcrypt from testing or unstable only support GnuPG. Therefor the package has been moved into non-us/main and is residing there. Thanks for clarifing your facts before. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpvlAGDiGHq9.pgp Description: PGP signature
Re: Debian audititing tool?
On 00-12-27 Peter Palfrader wrote: On Wed, 27 Dec 2000, Christian Kurz wrote: On 00-12-27 David Wright wrote: Quoting Christian Kurz ([EMAIL PROTECTED]): [ Stop sending me unnecessary Ccs.] | Date: Tue, 26 Dec 2000 16:02:30 +0100 | From: Christian Kurz [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Subject: Re: Debian audititing tool? | Message-ID: [EMAIL PROTECTED] | Mail-Followup-To: Christian Kurz [EMAIL PROTECTED], | [EMAIL PROTECTED] I must be missing something here. You're the second person in about as many days to ask for people not to send Ccs while including a mail-followup-to: header for their own address. What is the latter intended to do? I suspect that smartlist is playing here with the header as I normally set a "Mail-Followup-To: nobody". So you maybe should contact the listmaster for more information about this. (And stop those damn Ccs.) Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should be [EMAIL PROTECTED] on this list if you don't want CCs. You probably misconfigured your mutt. No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has the correct "Mail-Copies-To: never", which means that I don't want any copies of the answers. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-27 David Wright wrote: Quoting Christian Kurz ([EMAIL PROTECTED]): [ Stop sending me unnecessary Ccs.] | Date: Tue, 26 Dec 2000 16:02:30 +0100 | From: Christian Kurz [EMAIL PROTECTED] | To: debian-security@lists.debian.org | Subject: Re: Debian audititing tool? | Message-ID: [EMAIL PROTECTED] | Mail-Followup-To: Christian Kurz [EMAIL PROTECTED], | debian-security@lists.debian.org I must be missing something here. You're the second person in about as many days to ask for people not to send Ccs while including a mail-followup-to: header for their own address. What is the latter intended to do? I suspect that smartlist is playing here with the header as I normally set a Mail-Followup-To: nobody. So you maybe should contact the listmaster for more information about this. (And stop those damn Ccs.) Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-27 Peter Palfrader wrote: On Wed, 27 Dec 2000, Christian Kurz wrote: On 00-12-27 David Wright wrote: Quoting Christian Kurz ([EMAIL PROTECTED]): [ Stop sending me unnecessary Ccs.] | Date: Tue, 26 Dec 2000 16:02:30 +0100 | From: Christian Kurz [EMAIL PROTECTED] | To: debian-security@lists.debian.org | Subject: Re: Debian audititing tool? | Message-ID: [EMAIL PROTECTED] | Mail-Followup-To: Christian Kurz [EMAIL PROTECTED], | debian-security@lists.debian.org I must be missing something here. You're the second person in about as many days to ask for people not to send Ccs while including a mail-followup-to: header for their own address. What is the latter intended to do? I suspect that smartlist is playing here with the header as I normally set a Mail-Followup-To: nobody. So you maybe should contact the listmaster for more information about this. (And stop those damn Ccs.) Mail-Followup-To: nobody is really wrong[TM]. Mail-Followup-To: should be debian-security@lists.debian.org on this list if you don't want CCs. You probably misconfigured your mutt. No, I mixed up Mail-Followup-To and Mail-Copies-To. Now this mail has the correct Mail-Copies-To: never, which means that I don't want any copies of the answers. Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: Christian Kurz [EMAIL PROTECTED] writes: Debsums seems to help a little bit - you can expect to catch some less-clueful intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. So you've effectively broken MD5 in a way that would yield useful results (ie would allow you to replace a specific binary with another specific binary, not with some more or less random garbage). How came it that you weren't prominently mentionend in this month's cryptogram? Small adnotation to this: If someone would have read the whole discussion about this, he would have found my explanation of this statement. But seems like some people always read only some mails and then make their assumptions. :( Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian audititing tool?
[ Stop sending me unnecessary Ccs.] On 00-12-26 Rainer Weikusat wrote: Christian Kurz [EMAIL PROTECTED] writes: Debsums seems to help a little bit - you can expect to catch some less-clueful intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. So you've effectively broken MD5 in a way that would yield useful results (ie would allow you to replace a specific binary with another specific binary, not with some more or less random garbage). How came it that you weren't prominently mentionend in this month's cryptogram? Why don't you get a clue and write again what I wrote? Here's a small hint: Does the author talks about himself or everybody? If you just want to do a bit of flaming then you should use someone else as your target. If not, I assume you haven't read the whole thread. Do this and then come back again. Ciao Christian
Re: Debian audititing tool?
On 00-12-26 Rainer Weikusat wrote: Christian Kurz [EMAIL PROTECTED] writes: [ Stop sending me unnecessary Ccs.] Start thinking about getting a decent mail client. My client is so decent, that it support a pure list-reply-function. Looks like your client is missing such a feature. and on the other hand you modify binaries so that the md5sum will still be the same. So you've effectively broken MD5 in a way that would yield useful results [...] Why don't you get a clue and write again what I wrote? Why don't you try this in German if your English is obviously to lacking to make any sense at all? Strange. The other readers on this list had no problem in understand my mail. So, you may just be missing a can, but if this the cause for your misunderstanding, I suggest that your parser is broken. Here's a small hint: Does the author talks about himself or everybody? Here's a small hint: | and on the other hand you modify binaries so that the md5sum will | still be the same. While this doesn't make any sense in the given context (see above), I'd translate it to: Man kann ein binary so verändern, daß der MD5-Hash gleich bleibt. Why do you think that it doesn't make any sense? So, either reformulate that in the way you really meant it or give some evidence to support it or put your head into a bathtub filled with cold water and try to cool of or little. As I wrote in my previous mail. If you want to flame someone, search for a better target. EOD.
Re: Debian audititing tool?
On 00-12-26 Peter Cordes wrote: have produced collisions in MD5. This is a Bad Thing for MD5, but it isn't a real break against MD5. It means that you can find two messages that hash to the same value. To do so, you _have_ to choose both messages yourself. If one of the messages is /bin/su, you are almost certainly out of luck. Nobody has figured out how to make another message that collides with a given message. It only works if they create _both_ messages. Cool, would you then please explain why Bruce Schneier writes about MD5: I am wary of using MD5 in his book Applied Cryptograhy and the end of the section about MD5? Ciao Christian
Re: Debian audititing tool?
On 00-12-21 Peter Cordes wrote: On Thu, Dec 21, 2000 at 03:37:56PM +0100, Christian Kurz wrote: On 00-12-21 Dan Hutchinson wrote: Sorry it was fornesics, but the code is basically matching the machine code, a unique pattern of 1's and 0's to the machine code of the kernal. Well, but then you need to know all patterns of malicous code that could occur. I think this will be a lot of patterns that you have to search for, so that the search will take a long time. Unless you have a kernal file that doesn't have 1's and 0's in machine language, you can scan the code. I am not sure how ASM code is written thou. Well, ASM (assembler) comes also down to 1 and 0 if you think about machine-code that is used by the processor. I thaught you wanted to scan the code that you find beneath /usr/src/linux. You have to search the binary kernel image. If you just scan the source, you have no way of knowing that the binary came from the source. Someone could hack the binary without changing the source. If there are any commonly-made changes to the binary, then you could look for them. Agreed, but then you have to scan the modules as well, as someone could change a module too or add one. It will be hard to do, and impossible to do perfectly. The Right Way is to keep a hash of your kernel binary so you know if it changes. BTW, md5 has not been broken, AFAIK, so there is no currently known way to change a binary without changing its MD5 hash, except trial and error, which would take a lot more _years_ than anyone would want to wait! You expressed doubt about this earlier. Rest assured that no real breaks in MD5 have been made public. (The NSA might have something, but they don't publish.) The md5sum manpage notes: The related MD4 message digest algorithm was broken in October 1995. MD5 isn't looking as secure as it used to. I just looked again in the Schneier to reread the paragraph about MD5. And if you use the compression function in MD5, you can produce collions like den Boer and Boesselaer proofed it. So, you should be careful about the usage of MD5 as Digest Algorithmen, because a basic design principles [of MD5] - to design a collision-resistant function - has been violated. So I would be very careful about the usage of this algorithmen. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpM3GraaEiwa.pgp Description: PGP signature
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: My suggested alternative is a system which knows about official Debian packages, and will register that change as simply "installed/upgraded package XYZ". Where should it register that? What exactly should it register? Your current description sounds like a system that just notes that package foo has been instaleld and nothing else. This will still make it possible to replace foo with an modified foo that allows someone to take your machine over. If you are willing to trust your Debian mirror (or perhaps you could even circumvent the mirror and go to .debian.org for signed checksums), Where do you have a signed checksum on .debian.org? the audit tool will tell you "replaced foo with upgraded (official) foo version#", or "ALERT: foo does not match official checksums". And how does it detect if the upgrade packageof official? Also the second detection will be based on the assumption that the file containing the checksum has not been replaced also. Hence my comment. "Less-clueful" intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so that debsum won't notice the difference. I think we're agreeing with each other. I said "debsums is inadequate", you appear to be trying to explain this to me. No, I tried to explain why it also won't work for the "less-careful" intruders, as they will use tools to hide their changes. Of course, at some point, you have to make a leap of faith. ATM, most Debian users trust their DNS server and their Debian mirror. IIRC, Connectiva's modifications to apt-get will fix the "trust your DNS" problem. Well, but you still have to trust your mirror and their admins? So how do you want to make sure that you can trust this mirror? Which modifications of apt are you talking about? What exactly did they modify? Did they change apt to not accept hostnames but only ip-address? http://freshmeat.net/news/2000/12/02/975819599.html Search for "mirror authentication". I'm not sure how they did it, but Well, no documentation about this available on the URL. if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key do you think of? Also this would impose that everyone downloads package from only one .debian.org server and this would generate a lot of traffic and resources on this machine. Or otherwise you have to convince every admin of .debian.org to generate a public key and install them all when you install apt. What do you define as "vanilla"? Also remeber that rootkits can change and become more sophisticated in the future. And so you will also be in a time lag behind the people having the rootkits as you first have to get a copy of it to create a detection for it. As new rootkits are observed "in the wild" (and a tool like this might help find them :), they can be added to the list of trojan signatures. This is closely analogous to the operation of virus scanners in M$ land. So you really think that someone who will write such a tool will be able to get acccess to all rootkits? I hope this is not meant serious. I'm not claiming to have a solution for automatic rootkit detection. As I said in the original email, kernel (and module) scanning is just an extra feature which is not perfect, but which might help somebody one day. Of course, there will always be new or mutating rootkits (like there are new or mutating virii on Windows), but if any rootkit is in widespread use, it will be detectable. And what about rootkits that are often used and not widespread but that you don't detect really? I think that also such a rootkit is already existing. * automatic recognition of changes to the snapshot which correspond to the installation of packages from /etc/apt/sources.list, possibly augmented by mirror authentication You still failed to describe how you want to do automatic recognition of packages. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: Sorry it was fornesics, but the code is basically matching the machine code, a unique pattern of 1's and 0's to the machine code of the kernal. Well, but then you need to know all patterns of malicous code that could occur. I think this will be a lot of patterns that you have to search for, so that the search will take a long time. Unless you have a kernal file that doesn't have 1's and 0's in machine language, you can scan the code. I am not sure how ASM code is written thou. Well, ASM (assembler) comes also down to 1 and 0 if you think about machine-code that is used by the processor. I thaught you wanted to scan the code that you find beneath /usr/src/linux. Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian audititing tool?
On 00-12-21 Peter Eckersley wrote: Basically, I started reading the tripwire documentation, stopped, and thought Debian ought to make this *much* simpler. It seemed that if I wanted to use tripwire, I'd need to tell it every time I was installing a new package. I'd then need to update a record on read-only media... Hm, looking at your statement above, I get the feeling that you have no idea, what the purpose of tripwire really is. If you use it without a read-only media to save the data too and rerunning it when you install software on the machine, it won't be very helpful to track an intrusion. Debsums seems to help a little bit - you can expect to catch some less-clueful intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. What I'd really like is this: A CDROM or boot floppy with a clean kernel, which downloads a set of clean md5sums from a trusted server, and checks those. It could then produce a list of modified configuration files, which one would need to check by hand. So, how do you define clean kernel? Which kernel is really clean? How do you define if a server is trustable and how do you make sure that no one has put modified binaries on it? * Kernel trojan scans for all known nasty kernel code. How do you want to do this with a source that is about 117M big? You have any idea how long it will take? Also you could hide nasty code very good in it and which will be hard to catch (This is an assumption by myself, after having looked at some parts of the kernel-source.) * Debian security servers - these could keep a record of which config file changes you've okayed. They might also allow you to checksum customised What? Mirrors worldwide for your config-files? Use tripwire and you don't need this. * Heuristic analysis scripts to look for funny things in users' home directories, such as SETUID stuff and questionable aliases in .bashrc, for example (although this can never be perfect). You want to scan user-dirs without telling them that you do this? In Germany you would better be careful with that as otherwise you could go into jail for doing this. Please think about respecting the privacy of your users. Does a tool like this exist already? If not, what do people think of the idea? No and I think on the one hand you have bit to much paranoia (Do you have two entrance doors, grilled windows. a complete list of everything in your house/flat in a safe by a lawyer? If no, I would suggest that you think about your ideas again.) and on the other hand you seem to have missed the idea behind tools like tripwire. Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: I would agree with your comments except the scan of the Linux Kernel. Thanks. :) You can use computer fornesics to scan the kernal against familiar trojan and virus patterns realitively quickly and at least identify problem Hm, you know that some parts are written in ASM and that you could also use ASM in some parts of the kernel to protect malicous code? How could a fornesics (Hm, do you mean forensic?) detect this asm-code and know that it is malicous? Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: On Thu, Dec 21, 2000 at 01:39:19PM +0100, Christian Kurz wrote: On 00-12-21 Peter Eckersley wrote: Basically, I started reading the tripwire documentation, stopped, and thought Debian ought to make this *much* simpler. It seemed that if I wanted to use tripwire, I'd need to tell it every time I was installing a new package. I'd then need to update a record on read-only media... Hm, looking at your statement above, I get the feeling that you have no idea, what the purpose of tripwire really is. If you use it without a read-only media to save the data too and rerunning it when you install software on the machine, it won't be very helpful to track an intrusion. I understand the requirement for read-only media. Tripwire should give me a clean snapshot of a system. But when I administer a machine, I regularly make changes to the clean image. If I want tripwire to track this, I must do the following every time I want to update the system: 1. Reboot with a clean kernel 2. Run tripwire with my read-only record 3. Install my Debian packages 4. Update my read-only record And you are running the system with an unclean kernel? If you not add your kernel that you are running to the tripwire check, you won't notice if anyone puts a bad module or a modified kernel on your system. My suggested alternative is a system which knows about official Debian packages, and will register that change as simply installed/upgraded package XYZ. Where should it register that? What exactly should it register? Your current description sounds like a system that just notes that package foo has been instaleld and nothing else. This will still make it possible to replace foo with an modified foo that allows someone to take your machine over. Debsums seems to help a little bit - you can expect to catch some less-clueful intruders with it, but it doesn't help in general. debsums just uses md5sums which can be manipulated on the one hand and on the other hand you modify binaries so that the md5sum will still be the same. Hence my comment. Less-clueful intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so that debsum won't notice the difference. What I'd really like is this: A CDROM or boot floppy with a clean kernel, which downloads a set of clean md5sums from a trusted server, and checks those. It could then produce a list of modified configuration files, which one would need to check by hand. So, how do you define clean kernel? Which kernel is really clean? How do you define if a server is trustable and how do you make sure that no one has put modified binaries on it? Of course, at some point, you have to make a leap of faith. ATM, most Debian users trust their DNS server and their Debian mirror. IIRC, Connectiva's modifications to apt-get will fix the trust your DNS problem. Well, but you still have to trust your mirror and their admins? So how do you want to make sure that you can trust this mirror? Which modifications of apt are you talking about? What exactly did they modify? Did they change apt to not accept hostnames but only ip-address? A kernel source is clean when it has the Debian kernel maintainer's signature on it. A kernel binary is clean when the administrator: Which signature? If you download a debian package there's no signature on it that you could check. So how do you want to check a signature and make sure that there's no poisoned kernel-source on your debian mirror? * gets a clean kernel source * compiles it, and records the md5sum of the kernel with the security server (or on a piece of paper). Of the kernel? What do you mean with kernel? Only vmlinuz? Or also the modules? Be more precise. * Kernel trojan scans for all known nasty kernel code. How do you want to do this with a source that is about 117M big? You have any idea how long it will take? Also you could hide nasty code very good in it and which will be hard to catch (This is an assumption by myself, after having looked at some parts of the kernel-source.) This service is not perfect, that needs to be made clear. However, it is reasonable to state that a large fraction of break-ins will use a vanilla rootkit, which might be detected even if the administrator *hasn't* recorded the custom kernel's checksum. What do you define as vanilla? Also remeber that rootkits can change and become more sophisticated in the future. And so you will also be in a time lag behind the people having the rootkits as you first have to get a copy
Re: Debian audititing tool?
On 00-12-22 Peter Eckersley wrote: On Thu, Dec 21, 2000 at 02:33:32PM +0100, Christian Kurz wrote: My suggested alternative is a system which knows about official Debian packages, and will register that change as simply installed/upgraded package XYZ. Where should it register that? What exactly should it register? Your current description sounds like a system that just notes that package foo has been instaleld and nothing else. This will still make it possible to replace foo with an modified foo that allows someone to take your machine over. If you are willing to trust your Debian mirror (or perhaps you could even circumvent the mirror and go to .debian.org for signed checksums), Where do you have a signed checksum on .debian.org? the audit tool will tell you replaced foo with upgraded (official) foo version#, or ALERT: foo does not match official checksums. And how does it detect if the upgrade packageof official? Also the second detection will be based on the assumption that the file containing the checksum has not been replaced also. Hence my comment. Less-clueful intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one, so that debsum won't notice the difference. I think we're agreeing with each other. I said debsums is inadequate, you appear to be trying to explain this to me. No, I tried to explain why it also won't work for the less-careful intruders, as they will use tools to hide their changes. Of course, at some point, you have to make a leap of faith. ATM, most Debian users trust their DNS server and their Debian mirror. IIRC, Connectiva's modifications to apt-get will fix the trust your DNS problem. Well, but you still have to trust your mirror and their admins? So how do you want to make sure that you can trust this mirror? Which modifications of apt are you talking about? What exactly did they modify? Did they change apt to not accept hostnames but only ip-address? http://freshmeat.net/news/2000/12/02/975819599.html Search for mirror authentication. I'm not sure how they did it, but Well, no documentation about this available on the URL. if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key do you think of? Also this would impose that everyone downloads package from only one .debian.org server and this would generate a lot of traffic and resources on this machine. Or otherwise you have to convince every admin of .debian.org to generate a public key and install them all when you install apt. What do you define as vanilla? Also remeber that rootkits can change and become more sophisticated in the future. And so you will also be in a time lag behind the people having the rootkits as you first have to get a copy of it to create a detection for it. As new rootkits are observed in the wild (and a tool like this might help find them :), they can be added to the list of trojan signatures. This is closely analogous to the operation of virus scanners in M$ land. So you really think that someone who will write such a tool will be able to get acccess to all rootkits? I hope this is not meant serious. I'm not claiming to have a solution for automatic rootkit detection. As I said in the original email, kernel (and module) scanning is just an extra feature which is not perfect, but which might help somebody one day. Of course, there will always be new or mutating rootkits (like there are new or mutating virii on Windows), but if any rootkit is in widespread use, it will be detectable. And what about rootkits that are often used and not widespread but that you don't detect really? I think that also such a rootkit is already existing. * automatic recognition of changes to the snapshot which correspond to the installation of packages from /etc/apt/sources.list, possibly augmented by mirror authentication You still failed to describe how you want to do automatic recognition of packages. Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-21 Dan Hutchinson wrote: Sorry it was fornesics, but the code is basically matching the machine code, a unique pattern of 1's and 0's to the machine code of the kernal. Well, but then you need to know all patterns of malicous code that could occur. I think this will be a lot of patterns that you have to search for, so that the search will take a long time. Unless you have a kernal file that doesn't have 1's and 0's in machine language, you can scan the code. I am not sure how ASM code is written thou. Well, ASM (assembler) comes also down to 1 and 0 if you think about machine-code that is used by the processor. I thaught you wanted to scan the code that you find beneath /usr/src/linux. Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
[ Would you please stop those Ccs to me?] On 00-12-21 Colin Phipps wrote: On Thu, Dec 21, 2000 at 03:30:25PM +0100, Christian Kurz wrote: Hence my comment. Less-clueful intruders won't modify /var/lib/dpkg/info/package.md5sums ; debsums will catch these people, but will not help if the cracker is smart. No, as it would say that if this md5sums will be wide spread, someone will write a tool to modify binaries without modifying the md5sum and then you have the problem again... This is not possible, that's the point of using md5sums in this case, it's computationally infeasible to construct a different file with the same md5sum. Sure, I haven't read the Schneier so far, but I'm not sure about this. ...or even create a tool that replaces the md5sum in the file /var/lib/dpkg/info/package.md5sum with a new one Which is why you would have to get the list of md5sums from a trusted source. No, I tried to explain why it also won't work for the less-careful intruders, as they will use tools to hide their changes. Some intruders will be careless or ignorant and it'll catch them. Others will be smart and it won't. Assuming at least some hackers are careless it's still worthwhile, in the absence of a perfect solution. Well and the one that you won't catch to much more damage to your system and create a higher risk then the one you catch. if I were trying to do mirror authentication, I'd ship apt with an official .debian.org public key, and then ask .debian.org whether a the public key presented by a mirror was kosher. There are other ways of doing it... puiblic key? GnuPG or PGP? Or do you mean ssh or what kind of public key do you think of? Also this would impose that everyone downloads package from only one .debian.org server and this would generate a lot of traffic and resources on this machine. Or otherwise you have to convince every admin of .debian.org to generate a public key and install them all when you install apt. No, you just sign all the packages on master.debian.org with this official key, and then mirror both the files and their signatures (as kernel.org do). And who will create this key? Who will have the passphrase? Who will sign the packages? How do you make sure that the signatures get's not corrupted? Ciao Christian -- Ein Nein ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein Ja um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi
Re: Debian audititing tool?
On 00-12-21 Colin Phipps wrote: On Thu, Dec 21, 2000 at 04:09:07PM +0100, Christian Kurz wrote: [ Would you please stop those Ccs to me?] If you don't want CC's then fix your mail headers: Mail-Followup-To: Christian Kurz [EMAIL PROTECTED], debian-security@lists.debian.org They are, as they contain: |Mail-Copies-To: never which means that I don't want a Mail Copy of an answer. On 00-12-21 Colin Phipps wrote: No, I tried to explain why it also won't work for the less-careful intruders, as they will use tools to hide their changes. Some intruders will be careless or ignorant and it'll catch them. Others will be smart and it won't. Assuming at least some hackers are careless it's still worthwhile, in the absence of a perfect solution. Well and the one that you won't catch to much more damage to your system and create a higher risk then the one you catch. Agreed, if someone gets root on your system there's no way you can guarantee detecting it. But you can try. Whether md5sums is worthwhile I don't know, I guess you'd have to look for some statistics on rootkits and such... Yes, such a statistic would be helpful as I think that only a small part of the rootkits are really know and every other rootkit is not know and only available in the underground. No, you just sign all the packages on master.debian.org with this official key, and then mirror both the files and their signatures (as kernel.org do). And who will create this key? Who will have the passphrase? Who will sign the packages? Someone on master.debian.org, presumably the ftp admins. And so you trust this admins? Just asking because some people here have a lot of paranoia. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp5OiN0HHYk5.pgp Description: PGP signature
Re: questions on ident, postfix proftp
On 00-12-17 Kevin van Haaren wrote: Ident questions Going through the Securing Debian HOW-TO I don't see a specific mention either for or against running the ident service (either through inetd or standalone.) Is there a consensus about if this service is particularly useful or not? It is useful to identify your users in case of abuse. Digging around on the internet it mainly seems to be useful for IRC clients although some mention is made that it can be useful for preventing users of your system from forging e-mail from your system. It will also be useful if any kind of abuse happens and your logfiles say nothing. If the admin can provide you with the ident-entry from your ident-server, you will still be able to identify the user, but if you have no ident running you will never find out which user abused your server. As far as security on the system itself it appears mainly to be a point of DoS attacks, is this a valid evaluation? IRC clients won't Well, depends on your identd configuration. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: questions on ident, postfix proftp
On 00-12-17 Kevin van Haaren wrote: Ident questions Going through the Securing Debian HOW-TO I don't see a specific mention either for or against running the ident service (either through inetd or standalone.) Is there a consensus about if this service is particularly useful or not? It is useful to identify your users in case of abuse. Digging around on the internet it mainly seems to be useful for IRC clients although some mention is made that it can be useful for preventing users of your system from forging e-mail from your system. It will also be useful if any kind of abuse happens and your logfiles say nothing. If the admin can provide you with the ident-entry from your ident-server, you will still be able to identify the user, but if you have no ident running you will never find out which user abused your server. As far as security on the system itself it appears mainly to be a point of DoS attacks, is this a valid evaluation? IRC clients won't Well, depends on your identd configuration. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpc9gZKF4yDW.pgp Description: PGP signature
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: What should a Debian-security metapackage should provide?
On 00-12-04 Javier Fernandez-Sanguino Peña wrote: (I'm taking this out of the previous thread) I've been giving some thought on a Debian metapackage related to security.. and I think that it might be useful to have a package that : Do we really need to discuss this again? There has just been one discussion about this and you can read about it in the archives. Ciao Christian P.S.: Turn that v-card off. -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp35uuc7EJc0.pgp Description: PGP signature
Re: Debian Security-HOWTO
[Please do not send me Ccs, I read the list where I'm posting to. If not I explicitly state this at the beginnning of my mail.] On 00-12-04 Javier Fernandez-Sanguino Peña wrote: Christian Kurz escribió: I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? As for the first one I do not know, maybe we should create a debian-security package to provide this kind of information like the java-common package provides the Java FAQ and the Java policy as Well, I think including this documentation into doc-debian would then be more sinful, because creating a new package for one document isn't a good idea. well as being a suited metapackage. How about having a package providing this document and some useful scripts (for example cron.daily updates from security.debian.org) and dependancies on security-related packages. Kind of a meta-package... No, we had one discussion about this some time ago and came to the conclusion that such a metapackage isn't a good idea. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. I'm not quite the same thinking here. You could use the powerful package management tools in order to automatically do this like: (user) - ok I want bind installed but chrooted in /home/bind (apt/dpkg) - downloading bind (apt/dpkg) - installing in /home/bind No, if you would have read the discussion on debian-devel you would also know, that this won't be possible. (apt/dpkg) - checking dependancies of bind (apt/dpkg) - moving related libraries (to allow dynamic linking) into /home/bind (apt/dpkg) - changing default init.d script to run bind but chrooted into /home/bind Can always be done via an external script, that the administrator starts, if he really wants to chroot the daemon. () (user) - dpkg --status bind (dpkg) Package: bind... Chrooted-in: /home/bind Won't work and I think this is somehting that Wichert won't include in dpkg. Also you should be free to choose the place to chroot for yourself. Did it make any sense? Some and please turn that v-card of. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpCR0X9pcyRf.pgp Description: PGP signature
Re: Debian Security-HOWTO
On 00-12-02 Wichert Akkerman wrote: Previously Christian Kurz wrote: How long is dpkg-statoverries available for debian? Couple of weeks. There is also the slight fact that the currently shipped version is subtly broken :(. It's still cool though! Well, from reading the changelog it's about 1 month ago and wasn't announced in a big form, so even I had no idea, that this tool exists until the discussion about it was started on -devel. I think the same applies to Alexander. But I think we will soon have some paragraph about dpkg-statoverride in it. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpalcF22sSxx.pgp Description: PGP signature
Re: Debian Security-HOWTO
On 00-12-01 Wichert Akkerman wrote: Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. How long is dpkg-statoverries available for debian? I think it was introduced only a very short time ago. So the author Alexander, had no time to really play with this tool and write a paragraph about it. (That's what I assume and may not be the reality, but I think I'm close to it :). Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: Debian Security-HOWTO
On 00-12-01 Wichert Akkerman wrote: Previously Javier Fernandez-Sanguino Pe?a wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). A quick peek shows that it doesn't document dpkg-statoverries, which is probably a very valuable tool for securing systems. How long is dpkg-statoverries available for debian? I think it was introduced only a very short time ago. So the author Alexander, had no time to really play with this tool and write a paragraph about it. (That's what I assume and may not be the reality, but I think I'm close to it :). Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpJwBu2ln4XV.pgp Description: PGP signature
Re: Debian Security-HOWTO
On 00-11-30 Javier Fernandez-Sanguino Peña wrote: I do not know if other developers are aware, but there is a nice Security HOWTO available in http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by Alexander Reelsen (which I am sending this to in case he is not on the list). I think he's reading this list as he's very security interested. I have checked it out and would really like to see it included in the DDP and think that debian security guru's should help in Well, which package should include this documentation? May I also say, that some debian security interested guys helped in creating this document? improving it. One thing I would like to have nicely documented is to make chroot jails. But not Linux-wide but Debian-specific, that is: What should be documented? Mostly you need to have all config files, libaries and binaries in the same structure as under / in a seperate dir, where you chroot to. is there a way to build packages available in Debian in order to easily install them chrooted? My first thought is that only if the You don't need to statically link packages to chroot them. You can also chroot them, if they use dynamic linking, but then you need to copy these libs also into the chroot-dir. ideas? Also, since the package would depend on other packages we need to have this in the chrooted environment too, is there an *easy* way to do this? (without needing to have two package databases) No, that's why I think chroots should always be set up by the admin and not by any tool. And a good idea knows how to create chroots even for programs using dynamic linking. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: task-unstable-security-updates?
On 00-11-19 Mike Fisk wrote: [big snip] Is that possible? Would the security team be willing to maintain such a pseudo-package? Something very close to this kind of task package has been discussed recently on debian-devel and we come to the conclusion that it won't be helpful or easy to maintain and the debian security guys already do a great job and spend lot's of time on fixing the security issues. So telling them to maintain such a package would increase their work-load without anu necessarity. And if you already run unstable (woody) on your system(s), then you should be able to just do an apt-get upgrade to get a fixed package. And those dependencies, as you suggest them, wouldn't help, because the old package doesn't exist anymore in the archives when the new get's installed. So instead of putting a higher burden on the securiy team, you should run regularly (once a week at least) apt-get upgrade if you have unstable and everything should be fine. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpImT9fzz84J.pgp Description: PGP signature
Re: scan debian packages for security vulnerabilitys big time
On 00-11-07 Andreas Schuldei wrote: * Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: [Changed Reply-To to point to the right list] Not so sure about that. I do NOT want the security issues to be an issue for the super advanced/paranoid/freaked-out-ones/security-aware ones. That is part This is the right list if we talk about security or extreme security-related things like a security audit of source code. -devel is not the right list and already cluttered with a lot of topic, so let's move it to the right list. of the idear. So I do not want the diskussion going on in some remote mailinglist but for everyone to see and read. If we do not get the idear It's not a remote list. It's a debian list which is open for everyone to join who has a interest in security. Please inform yourself better next time. across to lots of people, we will not win anything. todays volume of our Why? Can't we talk about the things for first on the correct list and then announce it to the people? Following your idea, we discuss everything now on -devel and remove -policy, -security, -user and so on. distrubution is out of hand. we have 4000 packages and are not enough (all developers that is, not just the ones reading debian-security) to look over our source in any time soon. And numbers get worse, if people are not educated. You talked first about OpenBSD, where only the base system is really audited and gets audited and now you talk about auditing 4000 packages? What the hell do you have in mind? Please make an exact statement what you want to audit? And please think very careful about the idea of auditing 4000 packages and if that's really needed. This won't be possible as you need a lot of knowledge about security and programming to do a real audit. It's not enough to have knowledge about security only or programming only, but it's the combination of both knowledges that allows you to do audits. We are running debian and most of us speaks at least one programming language. I guess within the last 3 to 5 years you have learnd things you were not even aware they existed. It is a continous process and why should it stopp at secure programming? Because not everyone is interested in programming even if he is a debian developer. You make assumptions here that are not correct and if you read the secure programming faq (You know the URL to it?), you should be aware that security audits of program code are not easy to do and only for advanced programmers and security people. Why don't you ask for help on this on security-audit? This list was originally created for doing audits of unix tools and is seldom used. (You should know this. :) I should, I am subscribed there. I also see how much progress is made. the majority of the mails form the last two weeks were of topic and about the brake in at Microsoft. I guess it were 10 Mails alltogether. You get my point? Yes, but why do you not ask on this list for help in auditing some source code and using the list for the things it was planned for? Just because currently it's close to dead and has off-topic stuff shouldn't stop someone from using it for the right things, which are on-topic there. I think, the long term perspective must be to have some AI (yes, SciFi) doing the simple audits. There is no other way to manage nowerdays amounts of code. And again I tell you there's no way to automatically do this or either the OpenBSD guys would already be using it? Why do you think they are just auditing the base system and not all the ports? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: scan debian packages for security vulnerabilitys big time
On 00-11-07 Andreas Schuldei wrote: * Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: [Changed Reply-To to point to the right list] Not so sure about that. I do NOT want the security issues to be an issue for the super advanced/paranoid/freaked-out-ones/security-aware ones. That is part This is the right list if we talk about security or extreme security-related things like a security audit of source code. -devel is not the right list and already cluttered with a lot of topic, so let's move it to the right list. of the idear. So I do not want the diskussion going on in some remote mailinglist but for everyone to see and read. If we do not get the idear It's not a remote list. It's a debian list which is open for everyone to join who has a interest in security. Please inform yourself better next time. across to lots of people, we will not win anything. todays volume of our Why? Can't we talk about the things for first on the correct list and then announce it to the people? Following your idea, we discuss everything now on -devel and remove -policy, -security, -user and so on. distrubution is out of hand. we have 4000 packages and are not enough (all developers that is, not just the ones reading debian-security) to look over our source in any time soon. And numbers get worse, if people are not educated. You talked first about OpenBSD, where only the base system is really audited and gets audited and now you talk about auditing 4000 packages? What the hell do you have in mind? Please make an exact statement what you want to audit? And please think very careful about the idea of auditing 4000 packages and if that's really needed. This won't be possible as you need a lot of knowledge about security and programming to do a real audit. It's not enough to have knowledge about security only or programming only, but it's the combination of both knowledges that allows you to do audits. We are running debian and most of us speaks at least one programming language. I guess within the last 3 to 5 years you have learnd things you were not even aware they existed. It is a continous process and why should it stopp at secure programming? Because not everyone is interested in programming even if he is a debian developer. You make assumptions here that are not correct and if you read the secure programming faq (You know the URL to it?), you should be aware that security audits of program code are not easy to do and only for advanced programmers and security people. Why don't you ask for help on this on security-audit? This list was originally created for doing audits of unix tools and is seldom used. (You should know this. :) I should, I am subscribed there. I also see how much progress is made. the majority of the mails form the last two weeks were of topic and about the brake in at Microsoft. I guess it were 10 Mails alltogether. You get my point? Yes, but why do you not ask on this list for help in auditing some source code and using the list for the things it was planned for? Just because currently it's close to dead and has off-topic stuff shouldn't stop someone from using it for the right things, which are on-topic there. I think, the long term perspective must be to have some AI (yes, SciFi) doing the simple audits. There is no other way to manage nowerdays amounts of code. And again I tell you there's no way to automatically do this or either the OpenBSD guys would already be using it? Why do you think they are just auditing the base system and not all the ports? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQnRePjvYjn.pgp Description: PGP signature
Re: log permissions
On 00-11-03 Ian wrote: There are too many to list, but here are some: -rw-r--r--1 root root 8232348 Nov 3 06:43 tripwire Maybe some logfile of tripwire? I don't know it's content so I can't make a judgement about it's security risk. -rw-r--r--1 root root10152 Nov 3 14:49 wdm.log Also I don't know what this file contains, but as the name suggest, it has been created by wdm. So it may contain information about who has logged into the box at which time. -rw-r--r--1 root root0 Nov 3 06:26 mysql.err Well, as the name suggest, this file will contain error messages of mysql but it's empty and so no risk. -rw-r--r--1 root adm 0 Oct 29 06:47 cfingerd.log Looks like cfingerd is writing a logfile about who has tried to finger which user on your box. I think it would be enough if it's readable to root and adm(ins). -rw-r--r--1 root root 8483 Oct 22 12:42 dmesg This one contains the information that you see while you are booting your PC. If you haven't put your box into a safe and removed every reset button and so, that no one will be able to reboot the system, this file won't be a security risk. If someone can reboot your server, he will get also this info. So in my opinion it's alright that everybody can take a look at it. -rw-rw-r--1 root utmp 320908 Nov 3 16:43 lastlog This file contains information about all users on your system and when they have logged in for the last time. I currently have no idea, which security risk should be opened when every user can take a look at this information. -rw-r--r--1 root root 947139 Nov 3 16:36 nmb I never saw a logfile with this name and "apt-cache search nmb", so I can't comment on that. why are these files read by all? I have "normal" users on my system, and although I trust them, these kinds of permissions make me feel a little paranoid. ie: they could be used by someone to investigate system use, etc.. Why don't you look into those logfiles for yourself and examine their content and then make a decision which logfiles you want to protect more? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 PGP signature
Re: log permissions
On 00-11-03 Ian wrote: There are too many to list, but here are some: -rw-r--r--1 root root 8232348 Nov 3 06:43 tripwire Maybe some logfile of tripwire? I don't know it's content so I can't make a judgement about it's security risk. -rw-r--r--1 root root10152 Nov 3 14:49 wdm.log Also I don't know what this file contains, but as the name suggest, it has been created by wdm. So it may contain information about who has logged into the box at which time. -rw-r--r--1 root root0 Nov 3 06:26 mysql.err Well, as the name suggest, this file will contain error messages of mysql but it's empty and so no risk. -rw-r--r--1 root adm 0 Oct 29 06:47 cfingerd.log Looks like cfingerd is writing a logfile about who has tried to finger which user on your box. I think it would be enough if it's readable to root and adm(ins). -rw-r--r--1 root root 8483 Oct 22 12:42 dmesg This one contains the information that you see while you are booting your PC. If you haven't put your box into a safe and removed every reset button and so, that no one will be able to reboot the system, this file won't be a security risk. If someone can reboot your server, he will get also this info. So in my opinion it's alright that everybody can take a look at it. -rw-rw-r--1 root utmp 320908 Nov 3 16:43 lastlog This file contains information about all users on your system and when they have logged in for the last time. I currently have no idea, which security risk should be opened when every user can take a look at this information. -rw-r--r--1 root root 947139 Nov 3 16:36 nmb I never saw a logfile with this name and apt-cache search nmb, so I can't comment on that. why are these files read by all? I have normal users on my system, and although I trust them, these kinds of permissions make me feel a little paranoid. ie: they could be used by someone to investigate system use, etc.. Why don't you look into those logfiles for yourself and examine their content and then make a decision which logfiles you want to protect more? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpkkV65NTQ1J.pgp Description: PGP signature
Re: trusted debian and echo
On 00-01-05 Othmar Pasteka wrote: echo? someone out there? Yes. hmm, once upon a time there was a topic on #debian-devel mentioning ejb that he is doing something with trusted debian. so i mailed him but never got a reply. does some1 know what he is planing todo? or where is this discussed? I think it has something to do with RSBAC (Rule Set Based Acces Control). You can find more information about this on www.rsbac.org Ciao Christian -- * Christian Kurz Debian Developer/QA-Team * * Use Debian - a free Operating System *
