SuSE Security Announcement - make-3.77
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 14 Feb 2000, Thomas Biege wrote:
The reason is simple: The bug wasn't known to the public and only the vendors got notified by me right after I found it. To give other linux ditributors the time to fix their stuff I wait some days before releasing our announcement.
Hope that explains everything.
The respect of your competition is more important then the security of your users? - -- ..Yashy ".. I used to get in more fights with SCO than I did my girlfriend, but now, thanks to Linux, she has more than happily accepted her place back at number one antagonist in my life.. " (Jason Stiefel, krypto@s30.nmex.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4uXDXFM22zL2gTQcRAqLAAJ9UmyzrWcRQ2L3Xy0SMEKf20qxcsgCeNtVJ TpB2I2qC/3yJUYX48W31y0Q= =4ek0 -----END PGP SIGNATURE-----
Actually it makes a whole lot of sense and it is a common practice. Since the bug was *unknown*, it made sense to delay the announcement and give other vendors a chance to fix the bug. Had the announcement gone out immediately it would have given crackers a chance to exploit the bug. Avi Yasholomew Yashinski wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 14 Feb 2000, Thomas Biege wrote:
The reason is simple: The bug wasn't known to the public and only the vendors got notified by me right after I found it. To give other linux ditributors the time to fix their stuff I wait some days before releasing our announcement.
Hope that explains everything.
The respect of your competition is more important then the security of your users?
-- Avi Schwartz Get a Life avi@CFFtechnologies.com Get Linux
On Sun, 27 Feb 2000, Avi Schwartz wrote:
Actually it makes a whole lot of sense and it is a common practice. Since the bug was *unknown*, it made sense to delay the announcement and give other vendors a chance to fix the bug. Had the announcement gone out immediately it would have given crackers a chance to exploit the bug.
How do we know it was unknown. Unpublished, probably; unknown, almost certainly not. It is logical that if you found the hole, you're not the only one capable of finding it, and therefore not the only one who has. Tell us we're not back to security through obscurity? How many other unknown bugs are people able to compromise us using? I thought one of the whole benefits of OSS was that security holes could be found quicker, published to the community (BugTraq anyone?), and patched by individuals while waiting for the vendor to do so. It's kinda like, oh and by the way I noticed that your front door hasn't been locking properly for weeks, but don't worry, because I contacted the lock maker, and they said that if you insert oil here, and loosen that screw there, the dead bolt will work properly now. "Your computer system and the data stored on it has been vulnerable to attacks for X days, but we thought that you'd rather wait until the vendor had had a chance to fix it, before we let you know." I accept that fixes to problems may not come immediatly, but I believe that if the anyone knows about holes in advance, it'll be the underground community, and that admins will be less at risk when they know about the hole. As the Security officer for a distribution without the resources to do it's own audits I've got to rely on public disclosure of holes before I can issue fixes. If you wait until vendors have had a chance to fix it before publicly releasing it, add on a few hours lag in me finding out (I'm not sitting at my computer 24/7, I have a life, college, work, etc.), some time for me to verify, test, repackage, write the advisory, and post the package/advisory, then you'll see my users are open to attack for quite a while longer than they should be. I believe in full disclosure. Sorry guys, I'm with the Yash-meister on this one. /cog
No, we are not talking about security through obscurity. It is common to notify the maintainers of a piece of software about a security hole before you notify the public to give them chance to fix the problem. If you find that the door locks are broken in your subdivision due to a manufacturing error, are you going to announce on the radio that the doors cannot be locked and invite every thief for a visit or are you going to replace the locks first and then notify everyone else about the problem? Avi cogNiTioN wrote:
How do we know it was unknown. Unpublished, probably; unknown, almost certainly not. It is logical that if you found the hole, you're not the only one capable of finding it, and therefore not the only one who has.
Tell us we're not back to security through obscurity?
How many other unknown bugs are people able to compromise us using?
I thought one of the whole benefits of OSS was that security holes could be found quicker, published to the community (BugTraq anyone?), and patched by individuals while waiting for the vendor to do so.
-- Avi Schwartz Get a Life avi@CFFtechnologies.com Get Linux
On Sun, 27 Feb 2000, Avi Schwartz wrote:
No, we are not talking about security through obscurity. It is common to notify the maintainers of a piece of software about a security hole before you notify the public to give them chance to fix the problem.
It may well be common, does that make it correct?
If you find that the door locks are broken in your subdivision due to a manufacturing error, are you going to announce on the radio that the doors cannot be locked and invite every thief for a visit or are you going to replace the locks first and then notify everyone else about the problem?
Fixing holes in software isn't as easy as just poping down to the shops to buy a new lock. If the problem affects quite a few people, and isn't fixable in a short space of time (time varies depending on severity), notify people then they can take steps to improve their security while the fix is being worked on, and may even help with the fix. A lock is not the only way to prevent access to your home, other steps can be taken if you suspect the lock may well be bypassable. If you aren't aware of the problem, you can't work around it, you can't take steps to fix it, you just keep on relying on it. /cog
Fixing holes in software isn't as easy as just poping down to the shops to buy a new lock. If the problem affects quite a few people, and isn't fixable in a short space of time (time varies depending on severity), notify people then they can take steps to improve their security while the fix is being worked on, and may even help with the fix. A lock is not the only way to prevent access to your home, other steps can be taken if you suspect the lock may well be bypassable. If you aren't aware of the problem, you can't work around it, you can't take steps to fix it, you just keep on relying on it.
Following the same logic, it's not always as easy to protect your system if there is a known hole, as it is for you to fix the security of your house in the event of a broken lock. In fact, you assume that you always can fix it yourself, or find a way to get around the bug until it is fixed. But let's face it, sometimes there's really nothing you CAN do until the vendors release a fix. So, on those lines, I still hold that it's better to be quiet than it is to let all of the hackers know.
On Sun, 27 Feb 2000, Daniel R. Gilliam wrote:
Following the same logic, it's not always as easy to protect your system if there is a known hole, as it is for you to fix the security of your house in the event of a broken lock. In fact, you assume that you always can fix it yourself, or find a way to get around the bug until it is fixed. But let's face it, sometimes there's really nothing you CAN do until the vendors release a fix. So, on those lines, I still hold that it's better to be quiet than it is to let all of the hackers know.
If you can't fix it, or make your system more secure/more closely monitored, then you could stop running the effected service, or take the box down completely, as a worse case senario. If you are unaware of it, then there is NOTHING you can do.
I agree with Avi...it's not a matter of eliminating security issues altogether, but more of a matter of minimizing the risk. Risk is minimized more by not saying anything for a short period of time, hoping that not too many hackers will get hold of the hole. It's not eliminated, as others probably will figure it out, but minimized; it's better to know that maybe just a couple of thieves in the subdivision know about peoples' lock malfunction than to alert all of the theives in the area that the whole subdivision is "easy pickin's". It's a bad deal either way, but we have to go with the lesser of the two evils. Dan
-----Original Message----- From: avi@CFFtechnologies.com [mailto:avi@CFFtechnologies.com] Sent: Sunday, February 27, 2000 8:02 PM To: cognition@bigfoot.com Cc: SuSE Security Subject: Re: [suse-security] SuSE Security Announcement - make-3.77
No, we are not talking about security through obscurity. It is common to notify the maintainers of a piece of software about a security hole before you notify the public to give them chance to fix the problem.
If you find that the door locks are broken in your subdivision due to a manufacturing error, are you going to announce on the radio that the doors cannot be locked and invite every thief for a visit or are you going to replace the locks first and then notify everyone else about the problem?
Avi
cogNiTioN wrote:
How do we know it was unknown. Unpublished, probably; unknown, almost certainly not. It is logical that if you found the hole, you're not the only one capable of finding it, and therefore not the only one who has.
Tell us we're not back to security through obscurity?
How many other unknown bugs are people able to compromise us using?
I thought one of the whole benefits of OSS was that security holes could be found quicker, published to the community (BugTraq anyone?), and patched by individuals while waiting for the vendor to do so.
-- Avi Schwartz Get a Life avi@CFFtechnologies.com Get Linux
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On Mon, 28 Feb 2000, you wrote:
No, we are not talking about security through obscurity. It is common to notify the maintainers of a piece of software about a security hole before you notify the public to give them chance to fix the problem.
Point is, you are probably not the only one who have found the weakness. IMHO, the time you wait to notify the public shouldn't be more than a couple of days. Of course, if its a *big bug* that will take TIME to patch, then give them some more time, but if its an unchecked buffer .. well. Release the bug after a day or two. That way, people may patch themselves, in addition to that you light a fire under the developers asses - thus ensuring that they release sooner instead of later. Oh, and those that don't follow bugtraq and notice the bug-announcement in the first place, probably won't notice that the vendor ships a patch neither. -- "Rune Kristian Viken" <arcade@kvinesdal.com> / arcade@irc (EFnet/IRCnet) Kvinesdalsnett System Administrator (http://arcade.kvinesdal.com/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole. This is just good security practice. It is hoped that, in turn, the other vendors will do the same. On Sun, 27 Feb 2000, Avi Schwartz wrote:
No, we are not talking about security through obscurity. It is common to notify the maintainers of a piece of software about a security hole before you notify the public to give them chance to fix the problem.
If you find that the door locks are broken in your subdivision due to a manufacturing error, are you going to announce on the radio that the doors cannot be locked and invite every thief for a visit or are you going to replace the locks first and then notify everyone else about the problem?
Avi
cogNiTioN wrote:
How do we know it was unknown. Unpublished, probably; unknown, almost certainly not. It is logical that if you found the hole, you're not the only one capable of finding it, and therefore not the only one who has.
Tell us we're not back to security through obscurity?
How many other unknown bugs are people able to compromise us using?
I thought one of the whole benefits of OSS was that security holes could be found quicker, published to the community (BugTraq anyone?), and patched by individuals while waiting for the vendor to do so.
-- Avi Schwartz Get a Life avi@CFFtechnologies.com Get Linux
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
__ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE4vQFyPYrxsgmsCmoRAl8QAJ95fAX6/0WNPrPuzjAFXRaxoUZhSwCfaYfV yHNcN32ixCzoMtdxdqExIK0= =1i6G -----END PGP SIGNATURE-----
On Wed, 1 Mar 2000, L. Sassaman wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
Have you got a link?
This is just good security practice. It is hoped that, in turn, the other vendors will do the same.
It still seems to me that this leaves more users open to attack. But, hey, what do I know. /cog
cogNiTioN wrote:
It still seems to me that this leaves more users open to attack. But, hey, what do I know.
Or are you just pissed off because you couldn't use that bug to exploit few systems? ...Just wondering why are you crying about common practice and hiding behind anonymity. (You aliases writing style just happens to be common to wanna-be crackers who think they are kEwL...) - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
On Thu, 2 Mar 2000, Jussi Laako wrote:
cogNiTioN wrote:
It still seems to me that this leaves more users open to attack. But, hey, what do I know.
Or are you just pissed off because you couldn't use that bug to exploit few systems?
On vaan turhauttavaa lukea posteja siitä kun ihmiset kinaa miten asiat pitäisi tehdä jossain. Parasta perustaa oma paikka turvallisuudesta kinaamiselle.
...Just wondering why are you crying about common practice and hiding behind anonymity. (You aliases writing style just happens to be common to wanna-be crackers who think they are kEwL...)
Tarkoittanet jotain nimimerkkiä Pete. Postiosoitteeni oli kyllä ihan normaalisti from kentässä... -Petri.Sirkkala@noitatieto.fi
- Jussi Laako
-- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Ups. Sorry, wrong cc: :) -Pete
On Thu, 2 Mar 2000, Jussi Laako wrote:
cogNiTioN wrote:
It still seems to me that this leaves more users open to attack. But, hey, what do I know.
Or are you just pissed off because you couldn't use that bug to exploit few systems?
...Just wondering why are you crying about common practice and hiding behind anonymity. (You aliases writing style just happens to be common to wanna-be crackers who think they are kEwL...)
Yep, hit the nail on the head there. I'm just some K-rad script kiddie with nothing better to do than break into people's systems and fsck up the system. Script kiddies rule. Hack the planet. It's go nothing to do with the fact that I'm trying to understand security principles, the whys and the hows; it's got nothing to do with the work I'm doing with the Indy Linux distro. (http://independence.seul.org/security/) [Where incidently, you will find my real name, since you seem to have a problem with the one I prefer to go by]. It can't just be because I'm interested, as a system admin who is having to deal with two possible breaches, on two seperate systems. I can't just be interested in debating and improving my knowledge in certain areas, can it. It can't just be because I don't fully understand why something is common practise, and decided to question it rather than follow the hurd. Nope. Today's youth don't do things like that. They're not interested in learning, in building, only in distroying. As for the alias; why not? I've been using it for a while, lots of people use it, I recieve junk mail through the post with it.... But you want to know why I decided to use one. Freedom. Online there is more freedom. You're not constrained by narrow minded sheeple who are unable to creatively develop their own opinion on someone, so they have to drop them into a nice stereotype they have lying around, be it based upon apperance, age, sex, religion, name, and they do so without having a clue who you are. (Well, thanks for being the exception), So I find that you can be someone else, it's almost a different personality, almost closer to the real me than I am. Why cogNiTioN? It's my goal, my aim. I believe that ultimate cognition will enable me to become at one with my surroundings, live in greater harmony, be more content, improve my quality of life, increase my ability to aid others towards happiness and contentness. Maybe I am hiding behind it. Maybe I'm hiding because in real life everytime I come out of hiding I get pushed back there by people like yourself, who judge without knowledge, and those who act without thought or respect. IRL I hide behind a fake me, that is really a mirror of what others want. Online I drop that brick wall I've built around my emotions, and instead I may well feel some comfort from going by a handle. As for the capitalisation, NTN, is close to TNT, which indicates the explosive nature of knowledge, how it can have an unforseen affect on everything in the vacinity. Fuck you. I was trying to debate a security issue on a security list, I was trying to improve my knowledge, understand more why things happen. You're opinion means jack to me, there are a few people on this list, that I've encountered else where, who I may care what they think of me, but you; if you're unable to get passed my name, then it's unlikely we'll have anything meaningful to say to each other. [BTW: "crying", I might have missed that post of mine, but I was trying to debate the issue, not cry about it.] I'm talking about computer security, oh no! I'm using a handle, oh no! You're first opinion of me was probably correct, oh knowledgable one. Script kiddies rule, Hack the planet. |<0n5id3R y0u'r3 s31f 0wn3d. Muhahahah, Muhahahaha. -cogNiTioN
cogNiTioN wrote:
Fuck you. I was trying to debate a security issue on a security list, I
Thanks. Conversation just didn't seem to go anywhere. Sorry for the flame, my mail was little too edgy. Just seen too many script kiddies trying to pull out information at newsgroups and mailing lists.
I'm talking about computer security, oh no! I'm using a handle, oh no! You're first opinion of me was probably correct, oh knowledgable one.
I think it's polite to use real name, especially when talking about security issues. Would you buy a lock or firewall from anonymous person? Or post announcement about security hole to k3wL-hAx0r5@hotmail.com who is asking just that?
Script kiddies rule, Hack the planet. |<0n5id3R y0u'r3 s31f 0wn3d. Muhahahah, Muhahahaha.
8-)=( = Grr - Jussi Laako P.S. I'll try to be silent for a while, or at least put my head to bucket of icy seawater before writing... -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
On Fri, 3 Mar 2000, Jussi Laako wrote:
cogNiTioN wrote:
Fuck you. I was trying to debate a security issue on a security list, I
Thanks. Conversation just didn't seem to go anywhere.
I agree, it doesn't. But I think it should.
I think it's polite to use real name, especially when talking about security issues. Would you buy a lock or firewall from anonymous person? Or post announcement about security hole to k3wL-hAx0r5@hotmail.com who is asking just that?
If the US Senate can look past someone's chosen name (didn't they ask l0pht, to take part in a discussion on locks?) then why can't you? I wouldn't buy a security product from anyone unknown to me, if a program, or author of the program has a good rep, i.e. others I know could recommend it, then yes I'd buy it, whether it be written by some 13 year old kid with a hotmail account and an alias, or by someone much older who uses their real name. In the past I've taken security advice, which as close as I get to buying a product, from people with aliases, and the alias wasn't even considered as an issue, only their knowledge, and experties. I feel sorry for you if you are unable to do likewise. Post a security announcement? Yep, would do. If I discovered a hole/problem, I'd release it to the public. i.e. I'd release it to anyone, and everyone, interested.
P.S. I'll try to be silent for a while, or at least put my head to bucket of icy seawater before writing...
I don't have a problem with you posting, unless you insist on just posting insults. Don't let me stop you making worthwhile contributions. /cog
[...] Ok, enough is enough, perhaps Jussi shouldn't wonder about what cognition (i prefer real names too but...), does with his time, but fuck you it's never a constructive answer for nothing. *JUST MY* opinnion: If you're able to release a good patch (or a workaround at least), for your reciently discovered security bug, then you should publish it, if not, *I* think that's better ask anyone who can release it before publishing the information, there's a lot of badhands out there awaiting for that kind of data. That's it. No need more lines saying dirty things about the mother of no one... :) Have a good one everybody. -- Francisco M. Marzoa Alonso Nuevo Mundo - Dpto. Informático ICQ#: 62850923 Henri Dunant, 19 - 28036 Madrid tfno: +34 91 343 18 40 ext. 207 España / Spain fax: +34 91 350 28 45
On Fri, 3 Mar 2000, Francisco M. Marzoa Alonso wrote:
[...]
Ok, enough is enough, perhaps Jussi shouldn't wonder about what cognition (i prefer real names too but...), does with his time, but fuck you it's never a constructive answer for nothing.
A discussion with someone who has already written you off because of your name is also rarely constructive. The only way that there is maybe scope to be constructive is to aid in the abolition of the predudice.
*JUST MY* opinnion:
If you're able to release a good patch (or a workaround at least), for your reciently discovered security bug, then you should publish it, if not, *I* think that's better ask anyone who can release it before publishing the information, there's a lot of badhands out there awaiting for that kind of data.
I like the idea previously suggested; Have a two stage advisory release, where the first advisory warns about the presence of the problem, what it affects and it's severity, released as soon as the problem is discovered, and then the next one is released when the patch is avaliable, and contains full details about the problem, exploit, patch, etc.
That's it. No need more lines saying dirty things about the mother of no one... :)
Have a good one everybody.
Will do, thanks. /cog
It seems this conversation is here to stay. I would see responsible to inform people if their locks can be picked, just don't tell how - to everyone - until someone works a fix for them. Ok? -Pete
It is in his latest Cryptogram. See www.counterpane.com for links. On Wed, 1 Mar 2000, cogNiTioN wrote:
On Wed, 1 Mar 2000, L. Sassaman wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
Have you got a link?
This is just good security practice. It is hoped that, in turn, the other vendors will do the same.
It still seems to me that this leaves more users open to attack. But, hey, what do I know.
/cog
__ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie
On Wed, 01 Mar 2000, you wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
I read that newsletter, and I have to fully disagree with him. Exploits points a finger, and says "look, its *very* vulnerable, fix it, quick". You don't know if you're the only one that knows about the vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service. Also, when you publish the exploit before a patch has been made, you light a fire under the program-makers asses. They have to work faster, and will release a patch earlier. They won't wait until their press-department has finished making a really nice looking press-release. THey will release the patch as soon as its finished, without delay. Give the program-developers a couple of days, at least if its only an unchecked buffer or something that can be fixed in a matter of seconds. (and before anyone starts ranting on about poor serveradmins getting their servers cracked because of exploits .. I've been cracked.. by the qpopper 2.2 exploit .. it was a horrible experience, but I do NOT blame the one who released the exploit. And I don't blame the makers of crowbars for breakins, or the weapon manufacturers for murder). -- "Rune Kristian Viken" <arcade@kvinesdal.com> / arcade@irc (EFnet/IRCnet) Kvinesdalsnett System Administrator (http://arcade.kvinesdal.com/)
On Sat, 4 Mar 2000, Rune Kristian Viken wrote:
On Wed, 01 Mar 2000, you wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
I read that newsletter, and I have to fully disagree with him.
Exploits points a finger, and says "look, its *very* vulnerable, fix it, quick". You don't know if you're the only one that knows about the vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
Do we really need an exploit, why? Is it not enough to inform that service this-and-that has a weak point, the authors have been informed and responsible admins might disable this service. You know, there is no technical solution to social problems.
Also, when you publish the exploit before a patch has been made, you light a fire under the program-makers asses. They have to work faster, and will release a patch earlier. They won't wait until their press-department has finished making a really nice looking press-release. THey will release the patch as soon as its finished, without delay.
If this is what you need an exploit for, well feel free to be exploitable. You see most programmers really do this for fun and perfection, not to be mocked and flamed. Have you ever considered making these things you are given free yourselves? Phew, it really makes no sense to make programs then. -Pete
Give the program-developers a couple of days, at least if its only an unchecked buffer or something that can be fixed in a matter of seconds.
(and before anyone starts ranting on about poor serveradmins getting their servers cracked because of exploits .. I've been cracked.. by the qpopper 2.2 exploit .. it was a horrible experience, but I do NOT blame the one who released the exploit. And I don't blame the makers of crowbars for breakins, or the weapon manufacturers for murder).
-- "Rune Kristian Viken" <arcade@kvinesdal.com> / arcade@irc (EFnet/IRCnet) Kvinesdalsnett System Administrator (http://arcade.kvinesdal.com/)
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 4 Mar 2000, Petri Sirkkala. wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
I read that newsletter, and I have to fully disagree with him.
I'm inclined to agree with Rune here.
Exploits points a finger, and says "look, its *very* vulnerable, fix it, quick". You don't know if you're the only one that knows about the vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
Do we really need an exploit, why? Is it not enough to inform that service this-and-that has a weak point, the authors have been informed and responsible admins might disable this service. You know, there is no technical solution to social problems.
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems.
Also, when you publish the exploit before a patch has been made, you light a fire under the program-makers asses. They have to work faster, and will release a patch earlier. They won't wait until their press-department has finished making a really nice looking press-release. THey will release the patch as soon as its finished, without delay.
If this is what you need an exploit for, well feel free to be exploitable. You see most programmers really do this for fun and perfection, not to be mocked and flamed. Have you ever considered making these things you are given free yourselves?
Programmers patch their exploited programs for fun? I don't see what gives you the right to tell someone they should be exploitable. That would be following the same belief that your peers are more important then your customers.
Phew, it really makes no sense to make programs then.
Because they can be exploited and will need patched?
(and before anyone starts ranting on about poor serveradmins getting their servers cracked because of exploits .. I've been cracked.. by the qpopper 2.2 exploit ..
Nice story. Too bad you weren't notified of the exploit earlier. Perhaps you were just waiting for your vendor to notify it's competition of the patch, which could have prevented the attack.
it was a horrible experience, but I do NOT blame the one who released the exploit. And I don't blame the makers of crowbars for breakins, or the weapon manufacturers for murder).
Some people want to know what weapons are available. I have to agree with "JuSSi" as well, anyone that uses an alias must be a malicious script kiddie. - -- ..Yashy - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GU/O/U d+ s:- a--@ C+++>$ U++++>$ P+ L+++>$ E--JOE W+++ N++ o-- K? w--- O M- V-- PS-- PE- Y++ PGP+++ t--- !5 X R tv-- b- DI-- D+ G e h--- r++ y++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4xFdvFM22zL2gTQcRAm5bAJ4/HoNYf3X4t8Qeb88HKOsi8uQBGQCePS9L fcXZUh9u5AiB3yfqSHeiU/Y= =+ZCI -----END PGP SIGNATURE-----
On Mon, 6 Mar 2000, Yasholomew Yashinski wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 4 Mar 2000, Petri Sirkkala. wrote:
Bruce Schneier has a very good piece about this. In it he condems publishing exploits, and *demands* that those who find exploits give the vendors ample time (not just a few days) to fix the hole.
I read that newsletter, and I have to fully disagree with him.
I'm inclined to agree with Rune here.
Exploits points a finger, and says "look, its *very* vulnerable, fix it, quick". You don't know if you're the only one that knows about the vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
Do we really need an exploit, why? Is it not enough to inform that service this-and-that has a weak point, the authors have been informed and responsible admins might disable this service. You know, there is no technical solution to social problems.
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems.
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues. If you find a bug, let the authors know first. If this does not work, then stop using their product, maybe make your own. And if the time taken by this process is an issue, think if you are really the first to know about the bug anyway? If you find out that doorlocks can be picked, you should not go out and nail posters around telling _how_ it can be done, but you should inform the makers of the locks and the shops that sell them, which take contact with the customers. Or so I think I would do.
Also, when you publish the exploit before a patch has been made, you light a fire under the program-makers asses. They have to work faster, and will release a patch earlier. They won't wait until their press-department has finished making a really nice looking press-release. THey will release the patch as soon as its finished, without delay.
If this is what you need an exploit for, well feel free to be exploitable. You see most programmers really do this for fun and perfection, not to be mocked and flamed. Have you ever considered making these things you are given free yourselves?
Programmers patch their exploited programs for fun? I don't see what gives you the right to tell someone they should be exploitable. That would be following the same belief that your peers are more important then your customers.
By 'being exploitable' I only referred to the attitude of flaming programmers, which does no-one any good and for one. I would feel exploited if I faced this kind of oppression. You know, I like to fix any bug I can as fast as possible. To be sure of what you are using you should make your tools yourselves.
Phew, it really makes no sense to make programs then.
Because they can be exploited and will need patched?
No, because 'this kind of public' seems to be backstabbing you. Why not ask first and fire the shotguns later? Demanding patches and updates is no better than asking for them. It might even turn out that a nasty letter to a developer might end a product. -Pete
(and before anyone starts ranting on about poor serveradmins getting their servers cracked because of exploits .. I've been cracked.. by the qpopper 2.2 exploit ..
Nice story. Too bad you weren't notified of the exploit earlier. Perhaps you were just waiting for your vendor to notify it's competition of the patch, which could have prevented the attack.
it was a horrible experience, but I do NOT blame the one who released the exploit. And I don't blame the makers of crowbars for breakins, or the weapon manufacturers for murder).
Some people want to know what weapons are available.
I have to agree with "JuSSi" as well, anyone that uses an alias must be a malicious script kiddie.
- -- ..Yashy - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GU/O/U d+ s:- a--@ C+++>$ U++++>$ P+ L+++>$ E--JOE W+++ N++ o-- K? w--- O M- V-- PS-- PE- Y++ PGP+++ t--- !5 X R tv-- b- DI-- D+ G e h--- r++ y++ - ------END GEEK CODE BLOCK------
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE4xFdvFM22zL2gTQcRAm5bAJ4/HoNYf3X4t8Qeb88HKOsi8uQBGQCePS9L fcXZUh9u5AiB3yfqSHeiU/Y= =+ZCI -----END PGP SIGNATURE-----
Petri Sirkkala. said:
On Mon, 6 Mar 2000, Yasholomew Yashinski wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[snip]
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems.
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
Getting too dependant on SuSE would be Bad. Not that I don't appreciate their efforts to fix problems, or that they don't do a good job of it. I do, and from what I've seen they do. but What if SuSE got bought by Bill Gates, who then said "SuSE is the BEST, MOST SECURE Linux dist EVER, and always will be! Send me your $$$." So the week after, sendmail gets hacked. But BG says, "We already fixed that in MY dist! We're the best! Send me more $$$!" So, how do you tell if you're _really_ hackable or not? How long should you have to wait to find out? If I'm responsible for the security of my system, I want to know _now_, both so I can fix the problem in a timely manner and so I can tell if ol' Bill is lying to me so I can take my business elsewhere. -John
On Tue, 7 Mar 2000, John Grant wrote:
Petri Sirkkala. said:
On Mon, 6 Mar 2000, Yasholomew Yashinski wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[snip]
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems.
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
I did not say _only_ suse. But so far I trust only the ones I can verify myself. This is what everyman has to determine themselves. -Pete
Getting too dependant on SuSE would be Bad. Not that I don't appreciate their efforts to fix problems, or that they don't do a good job of it. I do, and from what I've seen they do.
...CUT...
Petri Sirkkala. said:
On Tue, 7 Mar 2000, John Grant wrote:
Petri Sirkkala. said:
On Mon, 6 Mar 2000, Yasholomew Yashinski wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[snip]
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems.
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
I did not say _only_ suse. But so far I trust only the ones I can verify myself. This is what everyman has to determine themselves.
That's exactly my point. How do I know I can trust them without being able to double-check them? That's why I, as the person responsible for securing a system, need an exploit to be published as soon as it's known. I need to verify the bug on my system, and verify the fix once it's made available (or I've patched it myself, if I have source). Something else to consider.. a bug is not always found by an audit. Often, perhaps even most of the time, a security hole is found by someone being hacked, and the hackee tracking down how. In that case the exploit is _already_ known, so I'm already vulnerable. Publishing the exploit just makes _me_ aware of it, which is something I want to happen as soon as possible. Even if found by audit, there's no guarantee that no-one else has found it too, and is using it. Any way I look at it, it's my assets in jeopardy, and I want to be notified immediately so I can take steps to protect those assets. -John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 7 Mar 2000, Petri Sirkkala. wrote:
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
I did not say _only_ suse. But so far I trust only the ones I can verify myself. This is what everyman has to determine themselves.
I would love to be able to trust SuSE, on the same token I can't afford to wait while they notify their peers. So instead I have to lurk everywhere I can, such lists as bugtraq etc, and even areas that contain members of the "darkside". I prefer to be notified ASAP about exploits, not when it's "convenient". - -- ..Yashy When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*".' (By Linus Torvalds) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4xQJuFM22zL2gTQcRAoMSAKCAMGMKgbo6nQFgPogygeJOgrd/AwCeKLow Btw/hm6ZN2bSb1f+kARLkcY= =Wd5L -----END PGP SIGNATURE-----
hi there I don't know where is the problem ... All GOOD administrator must control security fails on their system And mustn't wait for security announcement ... I think that mailling lists are just there to keep us informed for a pb we ave not seen... Bye Julien Calvet Credit-Insurance PS : Sorry for my english
I would love to be able to trust SuSE, on the same token I can't afford to wait while they notify their peers. So instead I have to lurk everywhere I can, such lists as bugtraq etc, and even areas that contain members of the "darkside". I prefer to be notified ASAP about exploits, not when it's "convenient".
- -- ..Yashy When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*".' (By Linus Torvalds) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE4xQJuFM22zL2gTQcRAoMSAKCAMGMKgbo6nQFgPogygeJOgrd/AwCeKLow Btw/hm6ZN2bSb1f+kARLkcY= =Wd5L -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
How can I enable MD5 passwords on SuSE 6.3? Thanks in advance! Normando. -- Normando [enemy] Marcolongo (iW6OWQ) [] normando@studenti.ing.uniroma1.it LUG Roma - IEEE S.B. Roma - ALU [] (AX.25) IW6OWQ@IW7BNO.IPUG.ITA.EU
On Tue, 7 Mar 2000, Petri Sirkkala. wrote:
I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
Why? If you hang in UNIX circles long enough, you can learn all sorts of tricks, programming related or otherwise. Knowing the exact exploit is a helpful thing-- if you know how to do it, you can help harden your box(es) against the CONDITIONS that will lead to a compromise in many cases.
If you find a bug, let the authors know first. If this does not work, then stop using their product, maybe make your own.
Oh, come on. make your own? why not patch something that is already working well enough (at least for you to have been using it)? It doesn't even have to be a permanent fix, but just enough to cover the hole, e.g. replacing a gets() (btw, who the hell still uses that?) with a couple of more lines and fgets() in order to eliminate a buffer overflow.
If you find out that doorlocks can be picked, you should not go out and nail posters around telling _how_ it can be done, but you should inform the makers of the locks and the shops that sell them, which take contact with the customers. Or so I think I would do.
Not everyone is as helpless as that, and most UNIX admins are "locksmiths" of varying ability in their own right. On top of this, the general argument/flame over releasing/holding back exploit+working code is, in my mind, a bad thing (TM). So far, it seems most of the proponents of late disclosure tend to scream that early release of an exploit and code is bad in that you are putting the tools into the hands of the crackers, and that there is no point in releasing such information without a handy patch against it already available. This is complete and utter BS. Let me at least say why I think so :) It only takes one cracker with a mass netscan to find your box with the rootable service. It only takes one 'cracker' with contacts in security and software companies to get wind of an exploit and throw it to the wind of the underground. You can't just hide your head in the sand and pray that they will go away, because crackers are always looking for the latest new exploit to get more boxes for their stupid DDoS attacks. This is why full and early disclosure is a necessity-- while the service in question cannot be fixed because there is no patch, there *ARE* ways of protecting against remote types of exploits. Stricter firewall/tcpwrapper definitions, shutting down the service, etc. Even with local exploits there are steps that can be taken to avoid the conditions necessary for a root exploit. Naturally, this is only if you *know* how it is done.
By 'being exploitable' I only referred to the attitude of flaming programmers, which does no-one any good and for one. I would feel exploited if I faced this kind of oppression. You know, I like to fix any bug I can as fast as possible.
Doesn't everyone? Most open source type programs are written by people who actually use their own product-- or at least they have pride in their own product. dan
On Tue, 07 Mar 2000, you wrote:
So I tell you that you should use qmail because the latest sendmail is crackable. Is this true, or am I just spreading FUD? An exploit allows admins to try it on their systems. I don't care if it is a FUD or not. I only react to those mails originating from SuSE or the real vendors of the programs. These are of course the parties that need the exploits to verify the bug, and then send the _official_ security issues.
No. What was the average RedHat response time? 10 days or something? From publication of bug, to patch.. (Microsoft was 14 or 16 days or something). I don't want to wait 10 days for that information. I want to read it when the bug is discovered. I want to be able to shut down the daemon, and/or patch it within 24 hours of the publication.
If you find a bug, let the authors know first. If this does not work, then stop using their product, maybe make your own.
So, when I find the bug, I should send a notice to the author, and say nothing to the thousands of users of the product? Letting them live with a vulnerable server? No way. They have the right to know.
And if the time taken by this process is an issue, think if you are really the first to know about the bug anyway?
You cannot know that for sure.
If you find out that doorlocks can be picked, you should not go out and nail posters around telling _how_ it can be done, but you should inform the makers of the locks and the shops that sell them, which take contact with the customers. Or so I think I would do.
Yes I should. I should tell it to everyone, so that people change their locks ASAP.
No, because 'this kind of public' seems to be backstabbing you. Why not ask first and fire the shotguns later?
Its got nothing, NOTHING to do with backstabbing. Its got everything to do with *informing the public*. If it feels like backstabbing to the programmer, bad for him. Thats his problem. I don't want thousands of users of the program to be vulnerable, just to protect the programmers back. -- "Rune Kristian Viken" <arcade@kvinesdal.com> / arcade@irc (EFnet/IRCnet) Kvinesdalsnett System Administrator (http://arcade.kvinesdal.com/)
Could you please stop that useless discussion. This is just a replay of what people where discussing on bugtraq when it was still new. That's why the moderator of bugtraq kills those threads. All Arguments of all sides are already known. You are not going to convince anyone to change her/his view. You are just wasting bandwith. cheers afx -- SuSE Muenchen GmbH Phone: +49-89-42769-0 Stahlgruberring 28 Fax: +49-89-42017701 D-81829 Muenchen, Germany May the Source be with you!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 8 Mar 2000, Andreas Siegert wrote:
Could you please stop that useless discussion.
Discussing security announcments is useless discussion? Are you saying that on behalf of SuSE?
This is just a replay of what people where discussing on bugtraq when it was still new. That's why the moderator of bugtraq kills those threads.
All Arguments of all sides are already known. You are not going to convince anyone to change her/his view. You are just wasting bandwith.
What were the results of the bugtraq thread? Exploits are posted there as they are discovered. Perhaps if someone (yourself?) would make a stand on SuSE's take of the situation, the thread will be ended. In the meantime we'll have to debate our opinions which hopefully have some reflection on the opinions of SuSE, as the vendor. As Linux makes itself mainstream, large corporations have identified that, and will have to choose a vendor to use. I believe SuSE to be the best option currently, I just hope they can maintain that standpoint for me. I would like to present a vendor to my employer that releases bleeding edge exploits. Calling a client's issues "useless" is hardly a professional way to react. I would recommend satisfying the customers needs, and not making fun of their issues. - -- ..Yashy "I, of course, DENY I called judge Santiago Campos a FASCIST PIG" - Bill Payne - June 1998 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4xsDMFM22zL2gTQcRAmVSAJ43cavseYFSaCgILAj/hbRYO/g92ACfVpmH VSyVB68cAIIYvR7YKt6ZtKw= =Ps8N -----END PGP SIGNATURE-----
On Wed, 8 Mar 2000, Yasholomew Yashinski wrote:
On Wed, 8 Mar 2000, Andreas Siegert wrote:
Could you please stop that useless discussion.
Discussing security announcments is useless discussion? Are you saying that on behalf of SuSE?
One would assume so.
This is just a replay of what people where discussing on bugtraq when it was still new. That's why the moderator of bugtraq kills those threads.
Some of us were not on bugtraq when it was new. Not all of us were using linux, or even online then (bugtraq started '97 sometime?).
All Arguments of all sides are already known. You are not going to convince anyone to change her/his view. You are just wasting bandwith.
This does seem to imply that SuSE will not change it's mind on this issue (regardless of their users views) Just because you seem to be aware of both sides of the discussion, it isn't safe to assume everyone does.
What were the results of the bugtraq thread? Exploits are posted there as they are discovered. Perhaps if someone (yourself?) would make a stand
Exploits are NOT posted to bugtraq as they are discovered, I've spoken the Simple Nomad and will probably be mailing others, SN has told me that he too waits for vendors to release a patch (or gives them sufficient time to do so) before going public. It appears that it is common practice and, thanks to this thread, I am begining to understand the reasoning behind doing so. I still don't totally agree with it tho.
on SuSE's take of the situation, the thread will be ended. In the meantime
I have spoken off list with Thomas from SuSE, and he was willing to answer the questions I had about their policy (complete with a diagram!) regarding bug fixes. If you're interested I could forward this to you.
we'll have to debate our opinions which hopefully have some reflection on the opinions of SuSE, as the vendor. As Linux makes itself mainstream, large corporations have identified that, and will have to choose a vendor to use. I believe SuSE to be the best option currently, I just hope they can maintain that standpoint for me. I would like to present a vendor to my employer that releases bleeding edge exploits. Calling a client's issues "useless" is hardly a professional way to react. I would recommend satisfying the customers needs, and not making fun of their issues.
In defense of SuSE, this issue has been discussed under this thread for quite a while, and seems to be dying out, very little new ground is being covered. I think what was ment was that the _continuation_ of this discussion is useless. Perhaps on this list it is. Perhaps not. I for one am interested in continued research into this, to see what is happening, and why. Perhaps it might be a good point to refer those interested to your list, and have the discussion continued there? I'm not saying that this wasn't a good place to bring the topic up, but that perhaps it has gone it's distance here. I agree with you that SuSE would be foolish not to listen to the views of it's userbase (customers or otherwise), as I believe the GmbH (or similar) means they are a commercial entity and thus reliant upon it's users. They also can't fail to be aware that there are hundreds of other distributions that would be perfectly willing to listen to the views of it's users (Indy for example ;). /cog
Hi,
All Arguments of all sides are already known. You are not going to convince anyone to change her/his view. You are just wasting bandwith.
This does seem to imply that SuSE will not change it's mind on this issue (regardless of their users views)
Our behavior does also depend on other linux vendors. If we ignore them and send the bugs to the public as soon as we found them they will go crazy. And I think we have to respect and help each other.
I'm not saying that this wasn't a good place to bring the topic up, but that perhaps it has gone it's distance here.
Yes! Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
the reality: yesterday my neighbour locked her out of her flat, it is a new flat it is a new heavy door, with a new lock. when asked the service man replied: "we get in everywhere" but one is not allowed to watch, did anyone read the text from TAMU, and you know that a professional needs 10 secs to start my locked car without a key. so please can we have a separate thread for the 10days discussion ? yours delighted -- --- Engelbert Gruber --- SSG Fintl,Gruber,Lassnig A6140 Telfs Untermarkt 9 Tel. ++43-5262-64727 ---
Quoting cogNiTioN (cognition@bigfoot.com) on Wed, Mar 08, 2000 at 09:28:11PM+0000:
This is just a replay of what people where discussing on bugtraq when it was still new. That's why the moderator of bugtraq kills those threads.
Some of us were not on bugtraq when it was new. Not all of us were using linux, or even online then (bugtraq started '97 sometime?).
Well, the issue comes up on bugtraq every few months... The reason I am no longer on usenet is because everything is repeating itself there in even shorter cycles. Looks like no one reads archives and just blasts stuff to the world. Hmm, guess I am too old for this world :-(
All Arguments of all sides are already known. You are not going to convince anyone to change her/his view. You are just wasting bandwith.
This does seem to imply that SuSE will not change it's mind on this issue (regardless of their users views)
Our user base is much large than the one following this news group. And they tend to have quite different views. What you see on a mailing list like this one is just a peak of the iceberg.
Just because you seem to be aware of both sides of the discussion, it isn't safe to assume everyone does.
I would assume that anyone seriously interested does research bevore posting.
In defense of SuSE, this issue has been discussed under this thread for quite a while, and seems to be dying out, very little new ground is being covered. I think what was ment was that the _continuation_ of this discussion is useless. Perhaps on this list it is. Perhaps not. I for one
Maybe I was unclear, but that was exactly my intention. cheers afx -- SuSE Muenchen GmbH Phone: +49-89-42769-0 Stahlgruberring 28 Fax: +49-89-42017701 D-81829 Muenchen, Germany May the Source be with you!
Quoting Yasholomew Yashinski (yashy@yashy.com) on Wed, Mar 08, 2000 at 04:06:15PM -0500:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 8 Mar 2000, Andreas Siegert wrote:
Could you please stop that useless discussion.
Discussing security announcments is useless discussion? Are you saying that on behalf of SuSE?
Discussing security announcements is not useless. Repeating old discussions without new content is useless.
What were the results of the bugtraq thread? Exploits are posted there as they are discovered. Perhaps if someone (yourself?) would make a stand on SuSE's take of the situation, the thread will be ended. In the meantime we'll have to debate our opinions which hopefully have some reflection on the opinions of SuSE, as the vendor. As Linux makes itself mainstream, large corporations have identified that, and will have to choose a vendor to use. I believe SuSE to be the best option currently, I just hope they can maintain that standpoint for me. I would like to present a vendor to my employer that releases bleeding edge exploits. Calling a client's issues "useless" is hardly a professional way to react. I would recommend satisfying the customers needs, and not making fun of their issues.
I do not call clients opinions useless. I did not say in any words anything about release policies. I did not make fun of anyone. Please read what I wrote exactly. SuSE, like most vendors does not release exploits. We release warnings as soon as we can provide our users with a fix or workaround. Sometime this does not happen as fast as we would like it to happen. But we are only human after all. cheers afx -- SuSE Muenchen GmbH Phone: +49-89-42769-0 Stahlgruberring 28 Fax: +49-89-42017701 D-81829 Muenchen, Germany May the Source be with you!
Rune Kristian Viken wrote:
vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
After that it's race against time from sysadmin's point of view. Is admin fast enough to disable that service before someone breaks in? If only few peoples know about security vulnerability it's less likely that someone uses it in your system. If every script kiddie knows about it, then it's much more likely... How many people sit 24/7 reading security mailinglists? What if sysadmin is at weekend trip with his sailing boat? - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
Jussi Laako said:
Rune Kristian Viken wrote:
vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
After that it's race against time from sysadmin's point of view. Is admin fast enough to disable that service before someone breaks in? If only few peoples know about security vulnerability it's less likely that someone uses it in your system. If every script kiddie knows about it, then it's much more likely...
How many people sit 24/7 reading security mailinglists?
No SA worth the title would need to take that much time to keep up. Besides, that's like asking, "what if the night-watchman falls asleep?".
What if sysadmin is at weekend trip with his sailing boat?
If the night-watchman takes the weekend off then you get someone to take his place. Or you do without, make sure you lock the doors as best you can, and take your chances.
On Sat, 4 Mar 2000, John Grant wrote:
Jussi Laako said:
Rune Kristian Viken wrote:
vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
After that it's race against time from sysadmin's point of view. Is admin fast enough to disable that service before someone breaks in? If only few peoples know about security vulnerability it's less likely that someone uses it in your system. If every script kiddie knows about it, then it's much more likely...
Isn't it the SysAdmin's job (among others) to be quick in responding to security announcements?
How many people sit 24/7 reading security mailinglists?
So what's the option? Only release security announcements during working hours? Working hours in which time zone? A report released at 5pm Friday, may not be read until 9am Monday (or Tues if it happens to be a bank holiday) the next week. Are those who do keep up with their mail ment to be left open to attacks because some people may not read their mail for a few days? What about those people who admin their servers in their free time? I do most of my admin work between the hours of 10pm and 2am. One of the asumptions that has to be made (and I'd feel justified in making this assumption) is that people who are involved in security are aware of how time critical some things are, and will take the required steps to ensure they're server is not unprotected longer than they deem acceptable.
No SA worth the title would need to take that much time to keep up. Besides, that's like asking, "what if the night-watchman falls asleep?".
What if sysadmin is at weekend trip with his sailing boat?
I have all urgent mail (inc. some security reports) routed to my Mobile phone (via procmail and an SMS filter thing), I can't be the only person who has done that. It has been known for me to fix problems with a mail server, over SMS, while I've been at college, in a maths tute. Just because an admin isn't at a terminal, doesn't mean they can't do anything about it. Even while I was out of the country I recieved status reports on my servers, and if a security report had been released, I'd have received it and either found an internet cafe, or mailed the other admin and asked him to fix it. Security isn't a 9 'til 5 job.
If the night-watchman takes the weekend off then you get someone to take his place. Or you do without, make sure you lock the doors as best you can, and take your chances.
Well said. /cog
* cogNiTioN wrote on Sun, Mar 05, 2000 at 14:07 +0000:
On Sat, 4 Mar 2000, John Grant wrote:
Jussi Laako said:
Rune Kristian Viken wrote:
vulnerability. The only responsible thing to do, is to publish the exploit to as many security-mailinglists as possible, and let admins disable the buggy service.
Isn't it the SysAdmin's job (among others) to be quick in responding to security announcements?
And even when the annouce is delayed, and a patch is aviable, the Admin needs to install it, so it makes no difference: the admin needs to be fast.
What about those people who admin their servers in their free time? I do most of my admin work between the hours of 10pm and 2am.
Me too, but maybe in a different time zone...
What if sysadmin is at weekend trip with his sailing boat?
Yeah, of course, but even if the security problem report is delayed, he cannot upgrade the packages, so it hasn't such advantages to delay. Another thing: the argument was: delay the information, to give the maintainers time to prepare patches. This requires, that no other found the bug. But if no other found the bug, it would be the best to hide and forget the information completly... And I'm sure: an expirienced attacher/intruder get's such informations quickly, since he/she spent a lot of time searching for such things. They might attack if the find a security update somewhere. They have some time to test for vulnerabilities. And if the exploit becomes public, then they can try it on machines, since the admin cannot update just in time. IMHO it would be necessary to suggest a workaround (at least the "shutdown" method...) as soon as possible. BTW: I'm sure the most of the attackers now lot's more about bugs, exploits and so on like most of the administrators... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Sun, 5 Mar 2000, Steffen Dettmer wrote:
Isn't it the SysAdmin's job (among others) to be quick in responding to security announcements?
And even when the annouce is delayed, and a patch is aviable, the Admin needs to install it, so it makes no difference: the admin needs to be fast.
true.
What about those people who admin their servers in their free time? I do most of my admin work between the hours of 10pm and 2am.
Me too, but maybe in a different time zone...
Probably, I'm in the UK, and thus work from GMT.
What if sysadmin is at weekend trip with his sailing boat?
Yeah, of course, but even if the security problem report is delayed, he cannot upgrade the packages, so it hasn't such advantages to delay.
I was going to mention that, but forgot.
Another thing: the argument was: delay the information, to give the maintainers time to prepare patches. This requires, that no other found the bug. But if no other found the bug, it would be the best to hide and forget the information completly...
true. But that isn't the case, and never will be. Back to Security through obscurity.
And I'm sure: an expirienced attacher/intruder get's such informations quickly, since he/she spent a lot of time searching for such things. They might attack if the find a security update somewhere. They have some time to test for vulnerabilities. And if the exploit becomes public, then they can try it on machines, since the admin cannot update just in time.
This leads to another point, why release exploits at all?
IMHO it would be necessary to suggest a workaround (at least the "shutdown" method...) as soon as possible.
Perhaps. But this option is almost always open.
BTW: I'm sure the most of the attackers now lot's more about bugs, exploits and so on like most of the administrators...
That is evident by the fact that attacks are soetimes sucessful. If all admins were more knowledgeable than all attackers, then they wouldn't happen. Also, you don't get many 9-5 people attacking machines, to some admins it's just a job, to nearly all attackers, they have some other, and often greater, motivation.
* cogNiTioN wrote on Sun, Mar 05, 2000 at 17:20 +0000:
On Sun, 5 Mar 2000, Steffen Dettmer wrote:
What about those people who admin their servers in their free time? I do most of my admin work between the hours of 10pm and 2am.
Me too, but maybe in a different time zone...
Probably, I'm in the UK, and thus work from GMT.
And others work in the states. It's shows what you (==cognition) said: It isn't possible to get advantages by delaying (IMHO).
What if sysadmin is at weekend trip with his sailing boat?
Yeah, of course, but even if the security problem report is delayed, he cannot upgrade the packages, so it hasn't such advantages to delay.
I was going to mention that, but forgot.
Yepp, you told it, and I think you're correct.
Another thing: the argument was: delay the information, to give the maintainers time to prepare patches. This requires, that no other found the bug. But if no other found the bug, it would be the best to hide and forget the information completly...
true. But that isn't the case, and never will be. Back to Security through obscurity.
This was meant sarcastic... It should lead to:
This leads to another point, why release exploits at all?
If the argument of delaying would be right, it would be the best to not release exploits at all. I think, the past showed, that this won't work at all... Somebody would find the bug too, and nobody had a patch or so, bad... IMHO the best thing is:
IMHO it would be necessary to suggest a workaround (at least the "shutdown" method...) as soon as possible.
Perhaps. But this option is almost always open.
But to disable a service that has a serious securiy problem I need to know about it. That's why I subscribed to this list... It's not necessary to tell all details if a bug occurs. So an attacker couldn't use it easily, since he wouldn't know enough details, only the affected program.
Also, you don't get many 9-5 people attacking machines, to some admins it's just a job, to nearly all attackers, they have some other, and often greater, motivation.
And more time to "surf" around the net to find holes and informations... I think at least some of them use a fast infrastructure to communicate, if a "hobby-" attacker finds something, others get this information immediatly I think. Admins from different companies usually haven't so much communications by each other I think. So it's a difficult job... Well... I still think it's not a good idea to delay security announcements... Sometimes I get such security informations by PM oder from a linux user group or so earlier... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Steffen Dettmer wrote:
And I'm sure: an expirienced attacher/intruder get's such informations quickly, since he/she spent a lot of time searching for such things. They might attack if the find a security update somewhere. They have some time to test for vulnerabilities. And if the exploit becomes public, then they can try it on machines, since the admin cannot update just in time.
Consider all those scans that you can find in your logs. Are those attackers capable to keep track of the combinations of IP addresses, services and versions in a database ? Would they be capable, as soon as a vulnerability is known to them, to search their database for IP addresses with that particular version of that service ? I'm afraid a system administrator has to be informed on vulnerabilities as soon as they show up. In the worst case he might consider to shut down the service. But as long as he's not informed he doesn't know that he has a problem and his systems will be open for an attack. That's not what I prefer. Regards, Fred Mobach
cogNiTioN wrote:
Isn't it the SysAdmin's job (among others) to be quick in responding to security announcements?
Sure is, but smaller companies cannot afford ~6 sysadmins needed for the 24/7/365...
So what's the option? Only release security announcements during working hours? Working hours in which time zone? A report released at 5pm Friday, may not be read until 9am Monday (or Tues if it happens to be a
That's why we should first release update (possibly binary) and after 24 hours (or next monday) release source code patch and detailed information about the bug. I'm viewing it from statistical point of view. Let's say that 10 crackers know about the vulnerability (if we don't announce it to whole world), it's not very likely that YOUR system gets hacked. But if we announce it, then about 1000 or 10000 crackers will know about it. Now it's much more likely that YOUR system gets hacked? Something like your password. You can't make it absolutely secure (even with biometrics), but it's darn bad luck if someone guesses it. - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
On Mon, 6 Mar 2000, Jussi Laako wrote:
cogNiTioN wrote:
Isn't it the SysAdmin's job (among others) to be quick in responding to security announcements?
Sure is, but smaller companies cannot afford ~6 sysadmins needed for the 24/7/365...
Small companies need 6 admins? How small are these companies? I admin/co-admin 3 servers in my spare time, in addition to lots of theatre work and full time college. How many small companies have more than 3 servers (running different linux distros, and soon different OS's) connected to the .net 24/7? It doesn't take 6 admins to look after a server 24/7/365, a server doesn't need to be monitored 24hours every day, just at reasonable time intervals. It only takes one admin with a reasonable amount of interest in the job. Not someone who treats it as any other 9-5 job.
So what's the option? Only release security announcements during working hours? Working hours in which time zone? A report released at 5pm Friday, may not be read until 9am Monday (or Tues if it happens to be a
That's why we should first release update (possibly binary) and after 24 hours (or next monday) release source code patch and detailed information about the bug.
The above was ment as sarcasm, I believe a system admin shouldn't treat the job as a 9-5 one. You don't treat the security of your building as a 9-5 job, so why should you treat a computer any differently. When you leave your building for the night/weekend, it has video cameras that record and store information. You don't go in on monday, review the contents of Friday's video and workout that the place got broken into, or less maliciously, a lighting short circuit burnt the place down. You install burglar alarms and smoke detectors, most likely connected to the police or fire station.
I'm viewing it from statistical point of view. Let's say that 10 crackers know about the vulnerability (if we don't announce it to whole world), it's not very likely that YOUR system gets hacked. But if we announce it, then about 1000 or 10000 crackers will know about it. Now it's much more likely that YOUR system gets hacked?
Something like your password. You can't make it absolutely secure (even with biometrics), but it's darn bad luck if someone guesses it.
Passwords aren't secure. They're a trade off between ease and security. You could run dental/fingerprint/DNA checks on everyone who uses your system, but that would be inpracticle. I don't believe these proposals are inpracticle. /cog
cogNiTioN wrote:
Passwords aren't secure. They're a trade off between ease and security. You could run dental/fingerprint/DNA checks on everyone who uses your
Btw. there are few reasonably priced fingerprint readers (hardware) available. I would like to use one with Linux login and GPG. Does someone have any information about possible driver/software support for Linux? - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371
On Sat, 4 Mar 2000, John Grant wrote:
How many people sit 24/7 reading security mailinglists?
I assume people are subscribed because they want to recieve security updates are they're dicovered, not when someone decides they have time to post them.
No SA worth the title would need to take that much time to keep up. Besides, that's like asking, "what if the night-watchman falls asleep?".
I guess I should imform my employer (who I'm willing to bet is a bigger "player" then your employer), that I have to wait for the John Grant[tm] approval I'm worthy? If the night watchman falls asleep you should look for a new employee.
What if sysadmin is at weekend trip with his sailing boat?
If the night-watchman takes the weekend off then you get someone to take his place. Or you do without, make sure you lock the doors as best you can, and take your chances.
And so this states your position on security. Unlike you, I would assume most users on this list care about their systems/networks. -- ..Yashy "By golly, I'm beginning to think Linux really *is* the best thing since sliced bread." (By Vance Petree, Virginia Power)
Yasholomew Yashinski wrote:
On Sat, 4 Mar 2000, John Grant wrote:
How many people sit 24/7 reading security mailinglists?
I assume people are subscribed because they want to recieve security updates are they're dicovered, not when someone decides they have time to post them.
No SA worth the title would need to take that much time to keep up. Besides, that's like asking, "what if the night-watchman falls asleep?".
I guess I should imform my employer (who I'm willing to bet is a bigger "player" then your employer), that I have to wait for the John Grant[tm] approval I'm worthy? If the night watchman falls asleep you should look for a new employee.
What if sysadmin is at weekend trip with his sailing boat?
If the night-watchman takes the weekend off then you get someone to take his place. Or you do without, make sure you lock the doors as best you can, and take your chances.
And so this states your position on security. Unlike you, I would assume most users on this list care about their systems/networks.
please stick to facts - i am not interested whose boss is the bigger player or who is better in security - i am here for security and for discussion of it *greetz* from Vienna Trema ps flame me if you wish, i do not care -- Johann Georg Hautzinger, email: trema@eic.at, Tel.: 531 00 1907 Erste Bank AG - OE 0423 - Orga./Entw. Treasury u. Orga.Wertpapier Boersegasse 14, 1010 Wien http://treasury.erstebank.at
Hi, perhaps you should STOP this discussion now?!? ***This is a SECURITY mailing-list!*** Thanks in advance Christoph Wegener Yasholomew Yashinski schrieb:
On Sat, 4 Mar 2000, John Grant wrote:
How many people sit 24/7 reading security mailinglists?
I assume people are subscribed because they want to recieve security updates are they're dicovered, not when someone decides they have time to post them.
No SA worth the title would need to take that much time to keep up. Besides, that's like asking, "what if the night-watchman falls asleep?".
I guess I should imform my employer (who I'm willing to bet is a bigger "player" then your employer), that I have to wait for the John Grant[tm] approval I'm worthy? If the night watchman falls asleep you should look for a new employee.
What if sysadmin is at weekend trip with his sailing boat?
If the night-watchman takes the weekend off then you get someone to take his place. Or you do without, make sure you lock the doors as best you can, and take your chances.
And so this states your position on security. Unlike you, I would assume most users on this list care about their systems/networks.
-- ..Yashy "By golly, I'm beginning to think Linux really *is* the best thing since sliced bread." (By Vance Petree, Virginia Power)
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- Ruhr-Universitaet Bochum Lehrstuhl für Biophysik c/o Christoph Wegener Gebaeude ND 04/Nord D-44780 Bochum, GERMANY Tel: +49(234)32-25754, Fax: +49(234)32-14626 mailto://cwe@bph.ruhr-uni-bochum.de http://www.bph.ruhr-uni-bochum.de __ _ / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . .
On Tue, 7 Mar 2000, Christoph Wegener wrote:
Hi, perhaps you should STOP this discussion now?!?
***This is a SECURITY mailing-list!***
Exactly. This is a discussion that is VERY relevent to security. Presumably you're on this list to be informed of security problems/fixes with your SuSE installation? I believe that the fact security problems could be with held from the public for upto a month, because it "seems fair" to the vendor is relevent to all those on this list. And to those people bashing SuSE, it isn't just them, I'm not sure to what extent they do so, but I've spoken to a few people who post announcements to BugTraq, and it appears that it is standard practice to leave the user vunerable while the vendor is contacted. I also think that this discussion is getting a bit stale. It seems that no new ground is being covered. What I am planning on doing is talking to a few other people (I've not seen any SuSE representative post on this topic, but would be interested if they could contact me off list), and as soon as I have the chance writting up an article with my conclusions about what currently happens and what changes (if any) I feel should be made. Are there any objections if I take some quotes from posts here? Thanks, /cog
Hi, I followed the discussion and here are some thoughts: There should be defenitely a Pre-Announcement with a vague descritption like "Make X.XX has a security problem that be exploited by people having login access to the PC getting root rights, the author is informed and will publish a patch/rewrite soon", within one or two weeks an in-depth description (probably with a patch) was released. Thus administrators could shut down affected services or take other steps to protect their systems as the pre-release is poblished. Given the fact that a hacker was investigating the code of this piece of software, he can be shure that many administrators have taken their steps to secure their systems and new code was released soon. Further investigation on this code was absurd and a waste of time for him like for all the other "problematic minds" out there as whatever they are likely to find will not let them intrude other systems. That way admins could have up to date security for their systems without giving hackers instructions to intrude systems. The messages indicate that many to most admins around here had not enough spare time to fix securtiy holes themselves (including me). For those who want to there could be an additional service, upon sending an e-mail message to e.g. the SuSE security staff, they could get detailed information by a GnuPG encrypted message. But they needed to supply their personal data to the security stuff, like written attestations from companies that they are the sysadmins of their servers. This on the base "if SuSE trust them not to take the information to exploit other systems, they must trust SuSE to treat their data confidential". For those who dislike aliases, imagine a MS employee who helps the open source community in his spare time. If his empoyer knew about his angagement it could make him unemployed. There are many good reasons for aliases! mike
Thomas Michael Wanka wrote:
There should be defenitely a Pre-Announcement with a vague descritption like "Make X.XX has a security problem that be exploited by people having login access to the PC getting root rights, the author is informed and will publish a patch/rewrite soon", within one or two weeks an in-depth description (probably with a patch) was released.
A good idea, but what to do with those working with another version of the same software product and as vulnerable as the one mentioned in the message. Nobody could test his installed version. Not on-topic on this SuSE security mailinglist but in general you can imagine that someone is using the same software product on another platform and would like to know if it's vulnerable ? How do you test it ? Or do you have just one possibility : disable the service / software ?
Thus administrators could shut down affected services or take other steps to protect their systems as the pre-release is poblished. Given the fact that a hacker was investigating the code of this piece of software, he can be shure that many administrators have taken their steps to secure their systems and new code was released soon. Further investigation on this code was absurd and a waste of time for him like for all the other "problematic minds" out there as whatever they are likely to find will not let them intrude other systems.
That way admins could have up to date security for their systems without giving hackers instructions to intrude systems.
See above.
The messages indicate that many to most admins around here had not enough spare time to fix securtiy holes themselves (including me). For those who want to there could be an additional service, upon sending an e-mail message to e.g. the SuSE security staff, they could get detailed information by a GnuPG encrypted message. But they needed to supply their personal data to the security stuff, like written attestations from companies that they are the sysadmins of their servers. This on the base "if SuSE trust them not to take the information to exploit other systems, they must trust SuSE to treat their data confidential".
OK, I'm having for almost 25 years my own business so I should send a letter to SuSE on my own paper admitting that I'm qualified to do the job ? Of course these rules can't be oppressed and SuSE has to make the decision if you're admitted to read the security alerts. In case they make a mistake, who would you blame ? They might oppress me to read the alerts and my systems are cracked. Are you then happy ? Or they permit me to read the alerts and someone else's system is cracked. Have I to be blamed then ? You see, more questions than reasonable answers. As always in security affairs, nothing is absolute, trust including.
For those who dislike aliases, imagine a MS employee who helps the open source community in his spare time. If his empoyer knew about his angagement it could make him unemployed. There are many good reasons for aliases!
Well said. Regards, Fred Mobach e-mail : fred at mobach.nl
Hi,
installation? I believe that the fact security problems could be with held from the public for upto a month, because it "seems fair" to the vendor is relevent to all those on this list.
(in SuSE's case) Nonsense! We write a fix right after the bug was dicovered. We send the fix plus bug description to other vendors. And gernerally we wait 3-5 days before releasing the advisory. I think this time is fair for everyone, the users/admins, the programmers and the vendors.
What I am planning on doing is talking to a few other people (I've not seen any SuSE representative post on this topic, but would be interested if they could contact me off list), and as soon as I have the chance
??? If you want to discuss something, contact us... Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
On 27 Feb 00, at 23:17, cogNiTioN wrote:
I believe in full disclosure.
Sorry guys, I'm with the Yash-meister on this one.
/cog
Hi, from your point of view a full disclosure defenitely makes sense. For others (like me), specially the ones running smaller networks with a rare (or no) chance to suffer from exploits from the network users, who have to care about intruders from the internet only (where the firewall should do the job), such a policy would have more disadvantages. I guess we needed a programm (some kind of list should do the job) where qualified admins get informed without giving information to hackers. I defenitly do not know how to seperate the good boys (or girls) from the bad. mike
I guess we needed a programm (some kind of list should do the job) where qualified admins get informed without giving information to hackers. I defenitly do not know how to seperate the good boys (or girls) from the bad.
That's simply not possible. So this approach is not feasible IMHO. Full disclosure is sometimes problematic but works rather well in general. I'd never trust anybody who is saying 'well, I know of a problem of yours, but I won't tell you'. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz ......................... poenitz@mathematik.tu-chemnitz.de
On 28 Feb 00, at 9:06, Andre Poenitz wrote:
That's simply not possible. So this approach is not feasible IMHO. Full disclosure is sometimes problematic but works rather well in general. I'd never trust anybody who is saying 'well, I know of a problem of yours, but I won't tell you'.
Andre' Hi,
how about private mail to registered users who signed up to receive this sevice? mike
Thomas Michael Wanka wrote:
On 28 Feb 00, at 9:06, Andre Poenitz wrote:
That's simply not possible. So this approach is not feasible IMHO. Full disclosure is sometimes problematic but works rather well in general. I'd never trust anybody who is saying 'well, I know of a problem of yours, but I won't tell you'.
how about private mail to registered users who signed up to receive this sevice?
This stuff has been discussed many times. There's just one problem, the list maintainer can't distinguish between well-behaving and bad-behaving subscribers. Or your mailinglist can't be used by people with a very good reason to hide their real name and address for others. That's the reason why this policy of publication is used, not only by SuSE but by everybody with security in mind. If you don't believe me, just take a look at the Bugtraq mailinglists at www.securityfocus.com. Select Forums from the home page and read the FAQ. Read some threads which start with a message from (by example) simple nomad or USSR folks. They always give the supplier / maintainer at least 2 weeks to solve a problem. Regards, Fred
On Mon, 28 Feb 2000, Fred Mobach wrote:
Thomas Michael Wanka wrote:
On 28 Feb 00, at 9:06, Andre Poenitz wrote:
That's simply not possible. So this approach is not feasible IMHO. Full disclosure is sometimes problematic but works rather well in general. I'd never trust anybody who is saying 'well, I know of a problem of yours, but I won't tell you'. ...
This is not the discussion I subscribe to this list for. Stop now or I ignore you for time being. -Pete
On Mon, 28 Feb 2000 Petri Sirkkala. wrote:
On Mon, 28 Feb 2000, Fred Mobach wrote:
Thomas Michael Wanka wrote:
On 28 Feb 00, at 9:06, Andre Poenitz wrote:
That's simply not possible. So this approach is not feasible IMHO. Full disclosure is sometimes problematic but works rather well in general. I'd never trust anybody who is saying 'well, I know of a problem of yours, but I won't tell you'. ...
This is not the discussion I subscribe to this list for. Stop now or I ignore you for time being. -Pete
Hi Pete, it's a security problem and a security mailing list. So I cannot understand you. Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 27 Feb 2000, Avi Schwartz wrote:
Actually it makes a whole lot of sense and it is a common practice. Since the bug was *unknown*, it made sense to delay the announcement and give other vendors a chance to fix the bug. Had the announcement gone out immediately it would have given crackers a chance to exploit the bug.
My mistake. I forgot that exploits are only found by the white-hats. As I said before, why notify your users of a security hole that could bring their network to their knees, when you have your competitors respect to worry about? - -- ..Yashy "...you might as well skip the (Christ)mas celebration completely, and instead sit in front of your linux computer playing with the all-new-and-improved linux kernel version." (By Linus Torvalds) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4uwtgFM22zL2gTQcRAp3oAJ0e6PgyoW86ZK3vz44uKMlzH6llTgCfUc6x u7lzzWQ/uPXygrKynaSGm6M= =EL6z -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 27 Feb 2000, Yasholomew Yashinski wrote:
-----BEGIN PGPENVELOPE PROCESSED MESSAGE-----
On Mon, 14 Feb 2000, Thomas Biege wrote:
The reason is simple: The bug wasn't known to the public and only the vendors got notified by me right after I found it. To give other linux ditributors the time to fix their stuff I wait some days before releasing our announcement.
Hope that explains everything.
The respect of your competition is more important then the security of your users?
I think that the concern here is for the security of all Linux users.
-- ..Yashy ".. I used to get in more fights with SCO than I did my girlfriend, but now, thanks to Linux, she has more than happily accepted her place back at number one antagonist in my life.. " (Jason Stiefel, krypto@s30.nmex.com)
-----BEGIN PGPENVELOPE INFORMATION-----
gpg: Signature made Sun Feb 27 13:45:43 2000 EST using DSA key ID BDA04D07 gpg: Good signature from "Yasholomew Yashinski (Do you send mail with an envelope or postcard?) <yashy@yashy.com>" gpg: key BDA04D07.1181: inserted into trustdb gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. gpg: Fingerprint: 0E59 01E6 0DF6 8EA9 EEBA 4E06 14CD B6CC BDA0 4D07
-----END PGPENVELOPE INFORMATION-----
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
__ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE4vQDIPYrxsgmsCmoRAsBpAKCMWadmd9QQtOMWVUfuhhtzdaL3UgCdE2jH RMOtgKAzDLOWtVN3ZVxkkS0= =VM3t -----END PGP SIGNATURE-----
participants (23)
-
Andre Poenitz -
Andreas Siegert -
Avi Schwartz -
Christoph Wegener -
cogNiTioN -
Daniel L. Donahue -
Daniel R. Gilliam -
engelbert gruber -
Francisco M. Marzoa Alonso -
Fred Mobach -
Johann G. Hautzinger -
John Grant -
Julien Calvet -
Jussi Laako -
L. Sassaman -
Martin P. Peikert -
Normando Marcolongo -
Petri Sirkkala. -
Rune Kristian Viken -
Steffen Dettmer -
Thomas Biege -
Thomas Michael Wanka -
Yasholomew Yashinski