-3

What is a vulnerability of this program?

I am currently stuck on a hacking exercise and have no idea what to do!

What do you think 'path' means? Because I think it's important.

#include <fcntl.h>
#include <limits.h>
#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(int argc, char *argv[])
{
  char buf[1024], path[PATH_MAX + 1];
  int fd, i;

  strcpy(path, getpwuid(getuid())->pw_dir);
  strcat(path, "/script.sh");

  strcpy(buf, "#!/bin/bash\necho Hello.\ndate\nrm \"$0\"\n");

  umask(0);
  if ((fd = open(path, O_CREAT | O_EXCL | O_WRONLY, 02760)) < 0) {
        perror("open");
        return 1;
  }
  write(fd, buf, strlen(buf));  
  close(fd);

  printf("please wait for us to run your script");  
  fflush(stdout);
  for (i = 0; i < 5; i++) {
        printf(".");
        fflush(stdout);
        sleep(1);
  }
  printf(" starting script\n");

  execl("/bin/sh", "/bin/sh", path, (char *) 0); 
  perror("execl");
  return 0;
}
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
CarolineRudolph
  • 101
  • 1
  • 10
  • SO is no consulting site. – too honest for this site Feb 23 '16 at 18:55
  • Are you asking for an explanation of somebody else's code? – Weather Vane Feb 23 '16 at 18:57
  • @WeatherVane Yes, this is a hacking exercise, and I am trying to find weakspots – CarolineRudolph Feb 23 '16 at 19:06
  • 1
    @CarolineRudolph you are aware that some of us are professional developers who have to spend extra time on backups and money on AV software to keep malware off our systems? You are asking us for help with hacking exercises? – Martin James Feb 23 '16 at 19:11
  • Like I am going to tell you how to pick the lock on my door... – Weather Vane Feb 23 '16 at 19:14
  • @MartinJames OP could be the one programming the flight control system for one your next flights. Knowing about *why* some programs aren't secure is important. – Daniel Jour Feb 23 '16 at 19:15
  • first problem I see - what if `getpwuid(getuid())->pw_dir` has length MAX_PATH? – Iłya Bursov Feb 23 '16 at 19:29
  • @DanielJour it is indeed. Surely, though, you are not using that argument as justification for assisting malware development on SO? – Martin James Feb 23 '16 at 19:32
  • @MartinJames How is this related to malware development? The code shown isn't for some kind of malware, it's a dummy example of a vulnerable program. Knowing why this program is vulnerable might prevent one from writing (production) programs with similar weaknesses. As far as I can see this causes only issues if having the above run as setuid program, right? – Daniel Jour Feb 23 '16 at 19:36
  • @MartinJames Thank you for your support. Yes, I am a whitehat in the making, studying how to spot vulnerabilities and how to fix them. I think shell injection (e.g. via nano) may be used here but not sure how. – CarolineRudolph Feb 23 '16 at 19:39
  • @Lashane that's a good spot! What are the implications of this? – CarolineRudolph Feb 23 '16 at 19:41
  • @CarolineRudolph buffer overflow – Iłya Bursov Feb 23 '16 at 19:53
  • 1
    erm, no. Much simpler. Have a look at the "printf("please wait for us to run your script");" prompt. Maybe the program is waiting for something else? In this context you also might want to have a look at the "umask(0)" statement and what it means. – tofro Feb 23 '16 at 19:58
  • Hm ... the script is created with SETGID set, which could be an issue. Modifying the script while the above program waits is also trivial, but the script isn't run with any root rights as far as I can see... – Daniel Jour Feb 23 '16 at 19:58
  • E.g. as for the modification part, try `./program_from_above & sleep 1; echo 'echo Sht' >> ~/script.sh` – Daniel Jour Feb 23 '16 at 20:00

1 Answers1

1

Well.

The program writes a script that it later executes with the permissions of the user.

The umask (0) system call actually makes that file world-writeable (implicitely - the open call makes it group-writable - Thanks to Daniel Jour for pointing this out-, but if the first command that anyone from your group would inject into that file would be a chmod, it could be escalated).

As pointed out in the comments, anyone from your group would be able to inject whatever he wants executed with the user's permissions and on the user's behalf by simply writing all the commands to that named file while the program is so nice and waits five seconds for him to do so.

And a short comment on "do not help people hacking" - comments: What the OP is doing is trying to learn about possible vulnerabilities in programs, and we're still on a pretty basic level here. Any programmer should be grateful if he is made aware of such possible pitfalls in his code. Trying to keep such stuff under the hood simply helps hackers and doesn't make anything more secure.

tofro
  • 5,640
  • 14
  • 31
  • That's right, but would you consider this a *vulnerability*? The program creates a file that later runs with the permissions of the same user that is calling it, so why bother and not enter the "malicious" code directly at the prompt instead of running above program? – Daniel Jour Feb 23 '16 at 20:06
  • Aslo, the file won't be world-writeable, it's actually `-rwxrwS---` (user: root, group: whatever-your-users-group-is) – Daniel Jour Feb 23 '16 at 20:08
  • Have you tried that? If yes, and you see -rwxrwS--- you are on a system (maybe Linux) that has acl enabled. There umask behaves different (with good reasons...). Without acl, umask(0) will, as I have pointed out, make the file actually world-writable. I recommend a man umask. And with /anyone/ above, I meant /anyone/, that is, all users on the system. That's the vulnerability – tofro Feb 23 '16 at 20:16
  • Are you sure? There's a call to `open` (not fopen) with mode `02760`. (Yes I ran the above, even with SETID) – Daniel Jour Feb 23 '16 at 20:18
  • 1
    I think you're wrong. The umask call means that no permissions from the mode given to open will be disabled. But since the mode for open explicitly disables world-access, the resulting file won't have world (writeable) access. (Also, my test system doesn't have acl, I just checked) – Daniel Jour Feb 23 '16 at 20:25
  • Ah, right. Wasn't really checking the permissions. How about group writable, then? Is that good enough for a vulnerability? I think so. – tofro Feb 23 '16 at 20:33