How to rm yourself

[c0n]

Kiddies cannot keep their hands off their . and / keys, though. They just go around ./'ing everything they can find vulnerable (which is very limited to them). Needless to say, if only real hackers know about it, then it isn't as big of a problem as it is with the kiddies. You don't have hundreds and thousands of little 14 year olds running around with codes that could potentially bring whole networks down when you don't disclose it, do you? There's a difference between fully disclosing shit (showing it to everyone on the net, which includes kiddies), and privately posting it to the vendor itself. Pr0j3kt M4yh3m for life. Props to Phrack High Council, h0no, dk, and other pr0j3kt m4yh3m cells for taking out the "big tough guys" in the whitehat security industry. It is a very big problem -- that is, the 'security industry'.

As I said, if a vulnerability is disclosed, then people have the opportunity to defend themselves against it.  I'd prefer having the chance to defend myself than to have the chance of a 0day I never knew about hitting me.  And to the people who don't keep up with the lists/updates, too bad for them. 

But then you have script kids who can do all these lame DoS attacks and try to 0wn your box. Wouldn't you prefer posting directly to the vendor in a private manner so that kiddies can't get their hands on it? Seems like a better idea to me...

That way you're still getting your patches from the vendor... and, surprise... no kiddies can 0wn you! You still, no matter what, have little protection against the big boys though ('big boys' not refering to boys with large penises).

[iago]

Kiddies cannot keep their hands off their . and / keys, though. They just go around ./'ing everything they can find vulnerable (which is very limited to them). Needless to say, if only real hackers know about it, then it isn't as big of a problem as it is with the kiddies. You don't have hundreds and thousands of little 14 year olds running around with codes that could potentially bring whole networks down when you don't disclose it, do you? There's a difference between fully disclosing shit (showing it to everyone on the net, which includes kiddies), and privately posting it to the vendor itself. Pr0j3kt M4yh3m for life. Props to Phrack High Council, h0no, dk, and other pr0j3kt m4yh3m cells for taking out the "big tough guys" in the whitehat security industry. It is a very big problem -- that is, the 'security industry'.

As I said, if a vulnerability is disclosed, then people have the opportunity to defend themselves against it.  I'd prefer having the chance to defend myself than to have the chance of a 0day I never knew about hitting me.  And to the people who don't keep up with the lists/updates, too bad for them. 

But then you have script kids who can do all these lame DoS attacks and try to 0wn your box. Wouldn't you prefer posting directly to the vendor in a private manner so that kiddies can't get their hands on it? Seems like a better idea to me...

That way you're still getting your patches from the vendor... and, surprise... no kiddies can 0wn you! You still, no matter what, have little protection against the big boys though.

Let's say there's a vulnerability in Apache 1.3.33 that some researcher discovered.  He decides to be responsible, and report it just to Apache. 

Now, what if some blackhats already knew about it.  They could use it to own my box and ruin my life, or whatever.  I would have preferred him to post it publicly, so I could defend myself, than post it privately, which left me wide open and naked. 

The sooner I know about something, the better.

Of course, there are other mitigating factors.  For example, all I have on that computer is Apache/MySQL, and it doesn't have access to any other computers on my network.  And the databases on it is backed up nightly.  So the most that could be done is a defacement and an annoyance.  But there is still a greater risk to me if vulnerabilities go undisclosed than if they are disclosed to all.

[c0n]

Kiddies cannot keep their hands off their . and / keys, though. They just go around ./'ing everything they can find vulnerable (which is very limited to them). Needless to say, if only real hackers know about it, then it isn't as big of a problem as it is with the kiddies. You don't have hundreds and thousands of little 14 year olds running around with codes that could potentially bring whole networks down when you don't disclose it, do you? There's a difference between fully disclosing shit (showing it to everyone on the net, which includes kiddies), and privately posting it to the vendor itself. Pr0j3kt M4yh3m for life. Props to Phrack High Council, h0no, dk, and other pr0j3kt m4yh3m cells for taking out the "big tough guys" in the whitehat security industry. It is a very big problem -- that is, the 'security industry'.

As I said, if a vulnerability is disclosed, then people have the opportunity to defend themselves against it.  I'd prefer having the chance to defend myself than to have the chance of a 0day I never knew about hitting me.  And to the people who don't keep up with the lists/updates, too bad for them. 

But then you have script kids who can do all these lame DoS attacks and try to 0wn your box. Wouldn't you prefer posting directly to the vendor in a private manner so that kiddies can't get their hands on it? Seems like a better idea to me...

That way you're still getting your patches from the vendor... and, surprise... no kiddies can 0wn you! You still, no matter what, have little protection against the big boys though.

Let's say there's a vulnerability in Apache 1.3.33 that some researcher discovered.  He decides to be responsible, and report it just to Apache. 

Now, what if some blackhats already knew about it.  They could use it to own my box and ruin my life, or whatever.  I would have preferred him to post it publicly, so I could defend myself, than post it privately, which left me wide open and naked. 

The sooner I know about something, the better.

Of course, there are other mitigating factors.  For example, all I have on that computer is Apache/MySQL, and it doesn't have access to any other computers on my network.  And the databases on it is backed up nightly.  So the most that could be done is a defacement and an annoyance.  But there is still a greater risk to me if vulnerabilities go undisclosed than if they are disclosed to all.

You bring up good points. However... let's say you didn't read the thousands of posts on BugTraq, and you soon find out a kiddiot has breached your invincible security. Now what?

append::

or let's say your patched the bug, but find out later that the patch was not completely a patch (it still left some holes open). Let's say that with minimal effort and knowledge, this kiddiot could somehow modify the exploit to hack the httpd. And this is because your patch did not successfully patch it. This being said, not to undermine your abilities, it is possible that a vendor patch would save you the trouble and *possibly* patch this hole completely. But then, you have other holes to patch (but you're not aware of this, because they are 0day).

[iago]

You bring up good points. However... let's say you didn't read the thousands of posts on BugTraq, and you soon find out a kiddiot has breached your invincible security. Now what?

I kick myself in the ass for not keeping up on vulnerabilities. 

Everybody who maintains computers ought to get their news in one way or the other.  Whether it's on BugTraq, TheRegister, Slashdot, Secunia, ISS X-Force, or any other newsletter, they should be reading it. 

And if they don't, as I said, too bad :)

[c0n]

You bring up good points. However... let's say you didn't read the thousands of posts on BugTraq, and you soon find out a kiddiot has breached your invincible security. Now what?

I kick myself in the ass for not keeping up on vulnerabilities. 

Everybody who maintains computers ought to get their news in one way or the other.  Whether it's on BugTraq, TheRegister, Slashdot, Secunia, ISS X-Force, or any other newsletter, they should be reading it. 

And if they don't, as I said, too bad :)

It's not bad to keep up on vulnerabilities, if that's what you thought I was saying. It does indeed reduce the risk. Though, like I said, you're not ruling out the kiddiots from grabbing all these exploits with full-disclosure. And doesn't coding an exploit and keeping it 0day just make it a 'little' more special? ;)

[iago]

It's not bad to keep up on vulnerabilities, if that's what you thought I was saying. It does indeed reduce the risk. Though, like I said, you're not ruling out the kiddiots from grabbing all these exploits with full-disclosure.

My other reason for liking full disclosure is simple: so I can demonstrate vulnerabilities to my superiors.  If another department has unpatched servers, they aren't going to listen to us until they know it's a threat.  If I can demonstrate a 1day or 2day to them, then they'll patch.  If I just tell them to patch, they probably won't and then they'll fall victim to your kidiots. 

But my point from my last post is that if people don't keep up with vulnerabilities in one way or another, it's their own fault when they get owned. :)

[c0n]

It's not bad to keep up on vulnerabilities, if that's what you thought I was saying. It does indeed reduce the risk. Though, like I said, you're not ruling out the kiddiots from grabbing all these exploits with full-disclosure.

My other reason for liking full disclosure is simple: so I can demonstrate vulnerabilities to my superiors.  If another department has unpatched servers, they aren't going to listen to us until they know it's a threat.  If I can demonstrate a 1day or 2day to them, then they'll patch.  If I just tell them to patch, they probably won't and then they'll fall victim to your kidiots. 

But my point from my last post is that if people don't keep up with vulnerabilities in one way or another, it's their own fault when they get owned. :)

If your superiors don't listen to you, then they fall victim to your "it's their own fault when they get owned" statement.

[iago]

If your superiors don't listen to you, then they fall victim to your "it's their own fault when they get owned" statement.

If you think that works on higher management, particularly in government, then you don't know much :-P

The view is, "somebody who isn't us has to take blame! Let's blame the security department!"

[c0n]

If your superiors don't listen to you, then they fall victim to your "it's their own fault when they get owned" statement.

If you think that works on higher management, particularly in government, then you don't know much :-P

The view is, "somebody who isn't us has to take blame! Let's blame the security department!"

I know it isn't how it works, and I was expecting you to say that. But it still fits into your category of it being their own fault (afterall, they did not listen)! So I guess the government and higher management are all ignorant, and won't take advice from an underling. It's their own fault.

[mynameistmp]

For instance, if you're running the current version of Apache httpd, you still are not safe from attacks to the Apache httpd, because someone could have found a vuln. And guess what, there isn't a patch out yet. So unfortunately, your only chance would be to plug the 0day vuln holes by coding your own patch.

What if I've got a network IDS running that's filtering for incoming shellcode ? What if I've got something like the grsec patch installed and his shellcode's offsets are fucked up because the stack is randomized ?

[iago]

For instance, if you're running the current version of Apache httpd, you still are not safe from attacks to the Apache httpd, because someone could have found a vuln. And guess what, there isn't a patch out yet. So unfortunately, your only chance would be to plug the 0day vuln holes by coding your own patch.

What if I've got a network IDS running that's filtering for incoming shellcode ? What if I've got something like the grsec patch installed and his shellcode's offsets are fucked up because the stack is randomized ?

IDS's don't filter, you're thinking of IPS's ;)

But at any rate, those aren't 100% reliable.  They're mitigating factors, for sure, but they might not save me from a smf sql-injection attack that cleverly evades the IPS, or an Apache format-string vuln that lets me overwrite some key address in Apache, giving me unlimited access or something? 

I'd still rather know about the vuln instantly so I can decide whether there is a risk to me or not, and act on it. 

[c0n]

For instance, if you're running the current version of Apache httpd, you still are not safe from attacks to the Apache httpd, because someone could have found a vuln. And guess what, there isn't a patch out yet. So unfortunately, your only chance would be to plug the 0day vuln holes by coding your own patch.

What if I've got a network IDS running that's filtering for incoming shellcode ? What if I've got something like the grsec patch installed and his shellcode's offsets are fucked up because the stack is randomized ?

Then you don't use the stack. So you see there are always ways around those kernel security modules. Ways around non-exec stacks, and your stack randomization.

edit: there are ways around everything.

[c0n]

http://screend-productions.net/images/giveadamn.gif

k guys, it's pointless to argue over this, it's not going to save either one of your computers from being smashed by some kiddie, end.

non-disclosure will.
btw, blackhats don't target random servers. That's why exploits are sager to only be in the hands of people who do not go around randomly defacing shit. If this happened, www.zone-h.org would be gone forever, and so will securityfocus! yay ;)

[mynameistmp]

 

But at any rate, those aren't 100% reliable.  They're mitigating factors, for sure, but they might not save me from a smf sql-injection attack that cleverly evades the IPS, or an Apache format-string vuln that lets me overwrite some key address in Apache, giving me unlimited access or something?

He said apache, not sql. I don't have sql running. The format-string idea sounds interesting, but unlikely. I'm pretty sure you'd need to inject shellcode anyways, because I don't think there's any code in apache that'd do you any good. And on top of that, grsec randomizes all user space memory objects. That would make it difficult to write to key addresses (if they do exist).

Then you don't use the stack.

grsec has ASLR (full adress space layout randomization). That includes: user space, kernel space, executable image, library images, etc, etc, etc.

So you see there are always ways around those kernel security modules. Ways around non-exec stacks, and your stack randomization.

What is the way around full address space layout randomization ?

[c0n]

But at any rate, those aren't 100% reliable.  They're mitigating factors, for sure, but they might not save me from a smf sql-injection attack that cleverly evades the IPS, or an Apache format-string vuln that lets me overwrite some key address in Apache, giving me unlimited access or something?

He said apache, not sql. I don't have sql running. The format-string idea sounds interesting, but unlikely. I'm pretty sure you'd need to inject shellcode anyways, because I don't think there's any code in apache that'd do you any good. And on top of that, grsec randomizes all user space memory objects. That would make it difficult to write to key addresses (if they do exist).

Then you don't use the stack.

grsec has ASLR (full adress space layout randomization). That includes: user space, kernel space, executable image, library images, etc, etc, etc.

So you see there are always ways around those kernel security modules. Ways around non-exec stacks, and your stack randomization.

What is the way around full address space layout randomization ?

If you do not know, then I have no reason to tell you. I am against full-disclosure 100%. So chances are I would never leak any unknown vulns. Do you rown research, find something cool, and realize that full-disclosure is a waste of talent. You spend hours and hours and hours research something, and it goes down a shit-hole with full-disclosure.