Results 1 to 4 of 4
  1. #1
    Ok, this is *very* obscure, but could, just possibly, be leveraged by an attacker.

    When called by cgi scripts, getlogin() returns the login name associated with the shell which started apache.

    Normally if apache is started at runtime or restarted via cron, this will just return "root". However, if an administrator logs in as themselves, uses su to become root, and then restarts apache, anyone who can create and run cgi scripts on the server can find out the login name of a user who knows the root password.

    Of course, on default installation of most operating systems you could get that same information by grepping /var/log/messages, so this is hardly a big security hole. But it is still an information leak, and on an extremely secure system it could be used by an attacker to determine which account he should try to break into to use as a stepping stone to root.

    What do people think... is this worth pointing out to the apache people?

  2. #2
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Originally posted by cperciva
    Ok, this is *very* obscure, but could, just possibly, be leveraged by an attacker.

    When called by cgi scripts, getlogin() returns the login name associated with the shell which started apache.

    Normally if apache is started at runtime or restarted via cron, this will just return "root". However, if an administrator logs in as themselves, uses su to become root, and then restarts apache, anyone who can create and run cgi scripts on the server can find out the login name of a user who knows the root password.

    Of course, on default installation of most operating systems you could get that same information by grepping /var/log/messages, so this is hardly a big security hole. But it is still an information leak, and on an extremely secure system it could be used by an attacker to determine which account he should try to break into to use as a stepping stone to root.

    What do people think... is this worth pointing out to the apache people?
    Well, this isn't really an issue. There's other ways to get that information. Basically, most systems allow any user to su to root, so it wouldn't matter what account you used (and if you had an account that you were able to use that function call, you already have an account on the system). Anyway, if you do have an account, you can try to su to root, unless it's configured to only allow people in the wheel group to su. If that's the case, and since you have an account on the system, you can simply look in the /etc/group file and see who's in the wheel group and allowed to su. Finally, most systems don't allow the average user to view the contents of /var/log/messages anyway. Of course, any information about a privileged account is best to be avoided. Anyway, getlogin() isn't a memory leak issue, and it only shows the current login in utmp.

    [Edited by Tim_Greer on 03-09-2001 at 06:43 PM]

  3. #3
    The issue isn't finding an account from which you can su to root -- as you point out, that is trivially done by looking at /etc/group. (Although I'm not sure if that is always world readable... anyone know for certain?)

    The issue is that this allows someone with cgi priviledges to find out who knows the root password. In that regard this is as much as security hole as logging in directly as root is: It lets the outside world know that you know the root password whereas using su doesn't (shouldn't) reveal that to the world.

  4. #4
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    First of all, I made a typo earlier, I meant "utmp", not "wtmp" in my last post. (I.e., /etc/utmp)... whereas this function simply grabs the current login, if any. It should and can do matching to ensure it's the user that's running the call too though, to prevent other information.

    Likely, people can just find out by typing "last" and seeing who logged in as root. I guess I didn't fully understand what you were saying before, but if you have access on a system and the su command is limited to only certain users, then those are the user's that know the password. Knowing whom knows the password though, isn't an issue. That doesn't help you to find out what the password is, it's a matter of finding out who can use the password and command.

    The only advantage to a system cracker, would be to know which specific accounts have the easiest access to the su command or aren't denied access. If you have access to a system that you can use the getlogin() function, then you have access to immediately see who logs in as root, even if they weren't the last person that logged in. If you (and you can) deny people that have accounts on the system from seeing the login's, etc. then that will deny the getlogin() function from displaying what you speak of anyway, since it grabs the information from utmp. If it doesn't have permission, you're safe from that revealing that information either way. Of course, that'd likely be in combination of other controlled things and denials of other commands too, to make any difference. But yes, the /etc/group file is alomost always readable by everyone on the system. The thing is, this isn't really an issue anymore than anything else, since you can have a CGI script to system calls that specifically run "last", "ps", "finger", etc.

  5. Newsletters

    Subscribe Now & Get The WHT Quick Start Guide!

Related Posts from theWHIR.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •