On Sat, Jun 02, 2001 at 05:20:01PM +0200, Boris allegedly wrote:
> Hello Johan,
> 
> 
> JA> Not quite. More like "someone inspects your free car and finds a button
> JA> that can make it explode. Maybe he pushes the button, maybe not. Maybe he
> JA> pushes the button on someone else's car". Are you willing to take that
> JA> risk? I can imagine two situations where that would be the case: either
> 
> Well, there is no button with a text like "press me here" -))))) for
> the public.

Of course there is, silly.

Tell us, your mail progam seems to be "The Bat! (v1.48f) Personal" -
did you write this program from scratch yourself or did you simply
click a few buttons and install the work of someone else?

Now, what do you think most script kiddies do? They don't scour the
code for exploits as you imply with "there is no button". They simply
download the hard work of one or two people and install the pre-built
button. It's trivial. So, "press me here" is as far away as a
download. You're not seriously suggesting this is a serious secruity
barrier are you?

> If we are talking about the security of a product, we have several
> things to take a look at. Internal security (a mailserver-only
> solution, mailserver+webserver, n mailservers, persons who access the
> mail queue as root). External security. Buffer overflows, chroot
> problems, jail problems, password problems. Design specific topics,
> what is secure, what is not secure, what can be implemented, what is
> not secure.

You are obscuring definition with implementation (and jargon for that
matter).

> As root i can read all the messages in clear text, sendmail or qmail -
> a security risk????? An attack to privacy? Or just a design problem?
> Or is it not a design problem, its just normal?
> 
> Security is relative.

No it's not. You're futzing and confused. This is real simple.

The security of a product is defined as a set of claims about
providing certain protection. A security problem exists when the
product does not meet a stated claim. Eg, qmail never claimed to
protect clear text messages on disk from root, so why did you bring it
up?

However, both qmail explicitly and sendmail (somewhat less explicitly)
do make claims about protecting against a user gaining elevated
priviledges. This thread started from yet another alert about being
able to corrupt the memory of sendmail. Corrupting memory is a tried
and true method of gaining elevated priviledges and time and again
this method *has* been used to gain elevated priviledges via sendmail.

In other words, sendmail has repeatedly failed to live up to it's
security claims and it looks like this current announcement may be
just another example.

So, inspite of what you say, you do not have to "have several things
to take a look at" and you don't have to understand sentences full of
buzzwords like "chroot problems" and "jail problems"...

You simply ask the question "has sendmail failed to live up to it's
security claims". The answer is a repeated "yes" bordering on
recidivism and no amount of obfuscation by you will change that fact.


Your sole defense is that sendmail doesn't make such security claims
explicitly and thus people are silly to infer such security. This is
indeed a strong argument.


Regards.

Reply via email to