What's this about "Evil Code" kernel bug?

> The problem is that none of these things actually close the hole. They
> are all ways to try to prevent the necessary condition that the hole
> be triggered, namely that someone runs the program on your machine.

Exactly my concern... to the best of my knowledge, the kernel people still
haven't fixed the underlying problem (the patch I saw was an incomplete
fix).

--
Jem Berkes
http://www.sysdesign.ca/

Bats wrote:

Well, thanks for all the info. I am surprised that this bug is still at
large! I hope this gets plugged right quickly, otherwise the Windows world
will really enjoy the fiasco!


--
Bats
~..~
(I can only post on weekends and rare times during the week.)

On 2004-07-11, Rowland <tramspap@comcast.net> wrote:

>>>If you don't
>>>provide untrusted shell access your risk is mitigated.


>>Forgive a simple one who does not grok the subtleties of security and please
>>explain how to check that I have not inadvertently provided such access.

> Filter out all incoming telnet and ssh with ipchains or iptables, and
> you won't have to think about it. We hope.

What about all incoming NetCats? How 'bout rsh's? Rexec's?

Or MySQL -> \! sysvbanner Get the idea\?


--
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

jayjwa <jayjwa@nowhere.org> wrote in
news:slrncfeklf.u9e.jayjwa@atr2.ath.cx:

> On 2004-07-11, Rowland <tramspap@comcast.net> wrote:
>
>>>>If you don't
>>>>provide untrusted shell access your risk is mitigated.
>
>
>>>Forgive a simple one who does not grok the subtleties of security and
>>>please explain how to check that I have not inadvertently provided
>>>such access.
>
>> Filter out all incoming telnet and ssh with ipchains or iptables, and
>> you won't have to think about it. We hope.
>
> What about all incoming NetCats? How 'bout rsh's? Rexec's?
>
> Or MySQL -> \! sysvbanner Get the idea\?

To be completely secure, dont connect to any other machine.
To be completely safe, remove all doors and windows from your home.

Gandalf Parker
-- "The way I heard it, If you arent going to pay attention to it then
dont leave it running."
"Your server? Daemons? Services?"
"I think my Mom meant the stove, but yes those also"

Bats <nomail@no.way> wrote in news:ccqplt$5gf$1@ctb-nnrp2.saix.net:

> John Thompson wrote:
>
>> If you don't
>> provide untrusted shell access your risk is mitigated.
>
> Forgive a simple one who does not grok the subtleties of security and
> please explain how to check that I have not inadvertently provided
> such access.

In its most obvious meaning it would be:

shell access = providing someone an account where they can access the
shell on your machine. A login/password they can use to reach the command
prompt to run programs on your machine

untrusted = how well do you know everyone who has access to your prompt?
Not just major access like having root password, but ANY level of access
which might be abused.

All absolutes are bad or worthless, everything is balancing the scales.
If you want to run services, let some people have user access, have your
machine be useful to others, then thats all fine. Now you are in the
position of needing to balance how many services, how many users, how
much access. As each of those increase, so will the security fun. :)

Gandalf Parker
-- "Virtual" Reality means almost as good as, reality. Keep that in mind
and dont make "virtual" things into such scarey new territory. Everything
I learned about security I learned from my Mother when I was growing up.