Sysmask security challenge: 1 week and +300 arbitrary code assaults, still resisting

Here it is:

http://wims.unice.fr/wims/wims.cgi?m...nice/challenge

It has received more than 300 arbitrary code assaults since its
startup, using sh, perl or c. Not only it is still resisting, but I am
bored not seeing even remotely threatening attacks.

Where are the true hackers? Maybe they are studying the challenge setup
(everything is published) and trying to find out a flaw? I hope to see
more ingeneous attacks in the future.

WARNING. You are not allowed to attack the server itself!

"azuredu" <xiao@unice.fr> wrote in message
news:1113983848.311402.270370@o13g2000cwo.googlegr oups.com...

> Where are the true hackers? ...
> WARNING. You are not allowed to attack the server itself!

"True hackers" don't play by your arbitrary rules.

> "True hackers" don't play by your arbitrary rules.

You may think that it is arbitrary rules for the time being. But the
challenge is in reality a demo of the new sysmask security package. So
the arbitrary rules may become standard one day. If you are a "true
hacker" and you don't know how to break this challenge, you will have a
hard life!

Documentation of sysmask:

http://wims.unice.fr/sysmask/doc/

"azuredu" <xiao@unice.fr> wrote in message
news:1113985239.650578.222780@z14g2000cwz.googlegr oups.com...

> > "True hackers" don't play by your arbitrary rules.
[...]
> So the arbitrary rules may become standard one day.

If you say so.

Under a sysmask-protected system, network daemons and network
applications are running under environments similar to that for the
submitted codes of the challenge.

When a hacker breaks a daemon or when a virus breaks a browser, it
encounters very similar situation as for the challenge. So if you don't
know how to break the challenge, you won't go very far by breaking a
daemon or writing a virus.

My own systems are already sysmask-protected. Worse than the challenge,
the protection rules are not published. The general public is
recommended to wait for sysmask-1.00 before installing it.

azuredu wrote:
> Here it is:
>
> http://wims.unice.fr/wims/wims.cgi?m...nice/challenge
>
> It has received more than 300 arbitrary code assaults since its
> startup, using sh, perl or c. Not only it is still resisting, but I am
> bored not seeing even remotely threatening attacks.

Well, I was one of the persons who decided to take a look. I entered
simple things, such as ls, echo * and so on, just to see what was there
to see, but all I got was "permission denied". So it didn't look to me
as if I was allowed to do anything even remotely interesting (like the
directory contents of /tmp or /), so I gave up. That should account for
almost 10% of the "arbitrary code assaults", which were no assaults at
all, but more like attempts to take a look. It's not that hard to make
a system secure by making it unusable.

I wouldn't draw the conclusion that sysmask is "still resisting". If
more people are like me, they'll be bored by the fact that they don't
seem to be able to do anything of interest.

I don't doubt that sysmask can be a useful addition to the linux
security toolkit, but it's hard to say so from the challenge.

Fun,

Stephan

> but more like attempts to take a look. It's not that hard to make
> a system secure by making it unusable.

This is the basis of "rule based access control": only "legitimately
need" accesses are allowed. And in the sh method, you do have access to
many things including everything in /usr/. However, to access /etc
(center of sensitive files) or /tmp (may contain information about
other users), you will have to break the protection at first.

The primary goal of the three methods is not to please attackers. They
will be teaching tools, letting students learn syntaxes and test
algorithms. For these purposes, the allowed accesses are amply
sufficient.

And sysmask protections on my working systems are all set in similar
ways. As for the challenge, an attacker or a virus will find the
break-in useless, but I myself now no longer feel the presence of the
protections during my normal work, except for the great feeling that no
infiltration nor virus may hurt me, even if my software versions are
often quite obsolete.

Take as an example my sshd. If you exploit a vulnerability in it (well
I don't know how), you will find the environement even more restrictive
than the challenge, with one big exception /etc/shadow that is
legitimately needed by sshd. But now I just don't care if somebody may
steal the file and crack my password: you could have passed the
authentication of sshd, but after that you still cannot get rid of the
sysmask restrictions. Only I myself know how to, and this time the
"password" is protected by sysmask as tightly as /etc/unreadable.52971.

That's why cracking sshd on my system cannot lead to successful
infiltrations. Well, unless the challenge is easily breakable.

In article <3cmgibF6lmq98U1@individual.net>,
"ynotssor" <ynotssor@example.net> writes:
|> "azuredu" <xiao@unice.fr> wrote in message
|> news:1113983848.311402.270370@o13g2000cwo.googlegr oups.com...
|>
|> > Where are the true hackers? ...
|> > WARNING. You are not allowed to attack the server itself!
|>
|> "True hackers" don't play by your arbitrary rules.

Precisely. Secure, rule-based environments are old hat, easy to
design and a partial solution. A much more serious problem is
ensuring that the rules are enforceable and enforced.

I run my Web browser as an unprivileged user in a chroot ghetto
that has no setuid programs, no devices and no files shared with
outside in it. Well, theoretically :-) In practice, I need some
to enable networking, and therefore they are its weakness. If I
were setting up a sandpit for kiddies to play in, and didn't need
to enable that, I could make it 'perfectly secure'.

Similarly, I do not allow users write access to my files. But I
need to investigate problems that they report, and there are some
circumstances when I need to use privileged tools on them. This
allows a loophole for a malicious hacker to write a Trojan horse.
In practice, this is not an issue here, but it assuredly is in
some environments.

Sysmask may be a useful approach, but it shouldn't be hyped into
a complete solution.


Regards,
Nick Maclaren.