Re: Rename root to avoid hacking?
From: Rick Moen (rick_at_linuxmafia.com)
Date: 09/23/05
- Next message: Unruh: "Re: Rename root to avoid hacking?"
- Previous message: Christopher Kerr: "Re: securing system after giving away root password"
- Maybe in reply to: Noozer: "Rename root to avoid hacking?"
- Next in thread: Unruh: "Re: Rename root to avoid hacking?"
- Reply: Unruh: "Re: Rename root to avoid hacking?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 22 Sep 2005 20:04:47 -0400
Roger Parks <dnlt0hn5ntzhbqkv51@safe-mail.net> wrote:
>> Local exploits that do this would have to be just the really incompetent
>> ones, as a _competent_ attacker who is able to operate at the level of
>> the local system would attack UID zero, instead. For remote, see below.
>
> I'm thinking of "logon" attacks from the wan, and mischievious,
> non-expert users spending hours guessing "root"'s password - hoping for
> a simple pwd.
Note: Those are remote attacks, not local ones. As mentioned, I
addressed those separately (further on, in my post). I did so because
I'm guessing that at least some remote attacks might need to invoke the
root user by name, but I am absolutely certain that no system-local ones
do. More about that immediately below:
> I don't understand how a non-root user can bypass the kernel and effect
> 000-level permissions without going through sudo/su. How would you do
> this?
By using the UID instead of the username, inside whatever you're doing.
Please note that (if I remember my C function calls correctly) referring
to a user by name merely results in a call to getuid(2) or geteuid(2),
so going directly to the UID by number is actually simpler.
Just to illustrate the point: There's an analogous (faulty) suggestion
people sometimes make for system-local security regarding access to
network services. (I can't remember the exact situation where this came
up, many years ago, but I'll reconstruct as best I can, from memory.)
Someone once was talking to me and saying that he'd blocked access to
(say) the RPC portmapper by removing the "sunrpc" (portmapper) line from
/etc/services.
I pointed out that this really doesn't work: All he'd done was prevent
local users (and their processes) from reaching the cited port by
_name_, but they could equally easily reach it by number. I illustrated
the point by showing that:
$ telnet linuxmafia.com smtp
and
$ telnet linuxmafia.com 25
...reach exactly the same SMTP daemon welcome banner. Comment out the
"smtp" line in /etc/services, and you'll prevent users from doing the
former but not the latter.
>>> This might work because the root password is typically very weak (we
>>> all do it on purpose, so as to allow easy logons and quick su/sudo.)
>>> (i.e. it is not 25 upper and lower case letters, characters and
>>> numbers)
>>
>> As a comment in passing, this is true only on systems that place
>> considerable trust in local users, and/or use wheel group protection.
>> Otherwise, admins who do that are making a grave mistake.
>
> Agreed. But in fact a lot of admins do use wheel - their argument
> being that they are dealing with the situation first hand and
> immediately.
You seem to be strenuously agreeing with me, here. ;->
(But I frankly don't use weak root passwords for wheel-group systems,
either.)
>> > I suppose another reason to consider it is help protect the user who
>> > loads up a "kitchen sink" distribution - i.e. a distribution that
>> > activates all sorts of mail, http, ftp, etc. servers with - optional -
>> > firewall activation which isn't activated .....
>>
>> Given that these don't run as the root user, the relevance is unclear.
>
> Here I'm thinking of the classic "buffer overrun allowing arbitrary
> code and escallated priviledges" vulnerabilities.
No, you see, such a process that starts out with even minimal privilege
is thus by definition a _local_ process, and so absolutely can always
refer to users by their UIDs. Which means that your remedy therefore
is of no use, there.
>>> (and the default for SSH is to allow root logins).
>>
>> Wrong remedy: Change that default.
>
> Well, yes... that's what I did.
I might add: Submit a bug to your Linux distribution. _Good_ Linux
distributions do _not_ have that default.
> But having no root -also- cures it if one doesn't know to disallow
> root.
Honestly, by the time people get to running fairly advanced network
services like SSH daemons, they no longer can reasonably invoke the "But
I didn't know any better" argument. They are making sysadmins of
themselves. They need to know better than to enable those things
without understanding their configurations -- or else misconfiguration
of /etc/ssh/sshd_config will be the _least_ of their problems.
> How does a user effect "000" level actions/permissions without going
> through the OS and su-ing up? i.e. su-ing up and having to crack the
> username (root) and password?
See above. su/sudo are not magic. They use run-of-the-mill system
calls that can be trivially invoked from (e.g.) basically any scripting
language.
>> Look, for example, at the configuration files for inetd/xinetd. Any
>> mentions of "root" in there? (Oops, there are! Sorry, users.)
>
> Yep.... you'd need to change the users from root to whatever the
> replacement name is.
>
> And I don't know what would become of the /root directory; 'twould be
> interesting to see what changed there after doing this.
Nothing would happen to it. And your altroot user could reference that
same location as its home directory in /etc/passwd.
My point, though, is that there may be many other places other than the
inet/xinetd configuration files, as well.
> Huh? You let non-root users into /etc? :-)
You may already know this, and are just kidding (so please don't take
offence): You actually cannot help letting non-root users into /etc,
for read access. As an experiment on a non-critical *ix system, some
time, observe what happens if you change /etc from 755 to 750
permissions. _Lots_ of stuff will break. Or just change /etc/passwd
from 644 to 640. If memory serves, you'll have immediately clobbered
the ability of any non-root user to login, among other things.
> Well, Rick, yours has been a constructive and informative post.....
> thanks for spending the time and responding with technical reasoning.
Yr. welcome.
--
Cheers, Mark Moraes: "Usenet is not a right."
Rick Moen Edward Vielmetti: "Usenet is a right, a left, a jab,
rick@linuxmafia.com and a sharp uppercut to the jaw.
The postman hits! You have new mail."
- Next message: Unruh: "Re: Rename root to avoid hacking?"
- Previous message: Christopher Kerr: "Re: securing system after giving away root password"
- Maybe in reply to: Noozer: "Rename root to avoid hacking?"
- Next in thread: Unruh: "Re: Rename root to avoid hacking?"
- Reply: Unruh: "Re: Rename root to avoid hacking?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
