Re: Compromise of the nobody account?

On Tue, 29 Jan 2008, in the Usenet newsgroup comp.security.unix, in article
<40444316-1278-4dd9-86f9-b3fb08642b29@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, mike3
wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

mike3 <mike4...@xxxxxxxxx> wrote:

Thanks for the good response. However, I still would like to know,
namely: what's the most damage a cracker could do running as
"nobody",

running _as_ "nobody", just as much as any "regular" user, but
only if the administrator is incompetent and altered the basic
configuration that prevents anyone from becoming "nobody" in the
first place.

could they potentially screw with the system memory using a program
running as "nobody" to execute malicious code somewhere else (like
overwrite part of a program that has much higher privilege (ie.
root) on it with some sort of malicious code that does something
like send "rm -rf /*" as root, grab /etc/shadow, launch a root
shell, etc.)?

User "nobody" (like every other user) may exploit an unpatched
or unknown security hole. Most UNIX admins take precautions that the
number of such holes is minimized.

Is it safe to be lax in one's estimation of the damage that could
be caused running as "nobody", or could quite a bit be done by a
clever enough cracker?

Is it safe for you to walk out to the street in front of your house
at 1 AM, place a black plastic shopping bag over your upper body, and
attempt to walk one mile in any convenient direction? Probably not
the best idea, but maybe nothing will happen other than the police
picking you up and putting you into the loony bin for your protection.
So, just as you wouldn't do something like that, why would anyone do
something equally senseless and disable or reduce the existing
protections of a computer?

Other possibilities I was thinking of would include a program that
for example tries to fill up the CPU or flood the network connections
with data (so if the system is a server, then doing this may hamper
use of the services it serves), or attempt to "zombify" the machine
and make it send packets like crazy to some site to as part of a DDoS
attack.

In this regard, user "nobody" is no more or less than any of the other
"system" user accounts - such as user "lp", "mail", "news" or "uucp".
They are all restricted accounts, and belong to an unused group, and
in most cases own no assets. As such, they are no more useful to a
cracker than the "nobody" account. ALL of these accounts are much
less useful than access to the "ordinary" user accounts, which
actually do have a password, and are likely to be allowed to log in
from outside the computer (unlike the system accounts).

Old guy
.

Relevant Pages

  • Re: Compromise of the nobody account?
    ... The administrator assigned "nobody" to have whatever shell is ... As far as the shell is concerned, ... Not that many systems use nobody to run a daemon. ... served going after one of the user accounts. ...
    (comp.security.unix)
  • Re: Compromise of the nobody account?
    ... "nobody" would normally be seen during the wee hours, ... UNIX is meant to be "professionally maintained", ... ALL of these accounts are much ... But is there a way that a cracker could try and access it from ...
    (comp.security.unix)
  • jadallah counters the fighter contrary to hers and publicly lets
    ... Nobody overnight sweep ... unless Taysseer locks planners in back of ... Hamid never accounts until Mustafa drinks the ... Austin it's relative wraping in front of a letter. ...
    (sci.crypt)
  • Re: Compromise of the nobody account?
    ... Find a real news server. ... what's the most damage a cracker could do running as ... running as "nobody", anyway, programs that didn't otherwise do so? ... ALL of these accounts are much ...
    (comp.security.unix)
  • Re: ZONE_PADDING wastes 4 bytes of the new cacheline
    ... > because nobody seems to be hitting the problems. ... I've some VM deadlocks in my queue, ... oom killer, that as well might not be strictly related, but there is no ... I tried to tune the protection sysctl, but that resulted in too much ...
    (Linux-Kernel)