[LivingNightmare]

Hi Everyone,

I wasn't sure if I should post this or not, since I know that DIC doesn't like 'security-based' questions, but I figured I would try my luck anyway, as I am completely stuck. For my security assignment, we were given a program with some flaws in it, and we are required to find 3 flaws that we can exploit to obtain root access to the system. I have managed to find two: a format string vulnerability and a buffer overflow. For the third one, I believe that I may have found something since the program crashes (when it shouldn't), but I am not incredibly familiar with some of the linux functions in this code snippet, so I wanted some help. The function where the segmentation fault happens is:

//Update entry in /etc/shadow
static
void update_spent(char * crypt) {
	FILE * old, * new;
	struct spwd * spw, spw_copy;
	char * username;

	link("/etc/shadow", "/etc/shadow~");
	unlink("/etc/shadow");
	lckpwdf();
	old = fopen("/etc/shadow~", "r");
	new = fopen("/etc/shadow", "w");

	printf("opening shadow files\n");
	username = get_username();
	spw = fgetspent(old);
	while (spw != NULL) {
		if (strcmp(username, spw->sp_namp) == 0) {
			memcpy(&spw_copy, spw, sizeof(struct spwd));
			spw_copy.sp_pwdp = crypt;
			putspent(&spw_copy, new);
			memset(&spw_copy, 0, sizeof(struct spwd));
		} else {
			putspent(spw, new);
		}
		spw = fgetspent(old);
	}
	fclose(old);
	fclose(new);
	unlink("/etc/shadow~");

	ulckpwdf();
}

The program receives a segmentation fault after printing "opening shadow files". The other two vulnerabilities were found by manipulation arguments passed to the program, but this one crashes just from calling it normally with no arguments (i.e leaving everything in it's default case). So I am 100% sure that the string crypt is a valid pointer in this case, and null-terminated.

So, I guess I should begin by asking: what is this shadow file and putspent/fgetspent functions? The link/unlink commands have me a bit concerned, although I don't see why this would cause a problem and make the program crash. Likewise, the lckpwdf function acts as a lock on the file I believe, so I think that this should be okay as well. Would anyone know why this function crashes? Sorry for the multiple questions... I usually program on windows, so I am not familiar with all of the linux concepts presented in this function. I should also mention that I am just looking for help in determining the reason why this crashes, and if this can be use as an exploit somehow... I'll write the code for the vulnerability myself.

Let me know if any clarifications are required, I would be glad to provide more detail or code if needed. Also, I apologize if this violates one of the rules for DIC (being security related and all), but I am not sure where else to post.
Thanks!

This post has been edited by LivingNightmare: 14 May 2012 - 09:49 AM

[Salem_c]

Well the first thing to do is something like

gcc -g prog.c
gdb ./a.out

Then run the code in the debugger to find out the real reason for the segfault.

Which on the whole would be much better than posting an incomplete program and "it doesn't work".

[LivingNightmare]

Hi Salem,

Thank you for taking a look at my problem. I am not too familiar with running GDB in the command line, but this is what I get when it crashes:

(gdb) backtrace
#0  0x401e68e7 in fgetpos () from /lib/libc.so.6
#1  0x40267139 in fgetspent () from /lib/libc.so.6
#2  0x0804929a in update_spent (crypt=0x40053140 "CTcCYms4VhjmM") at /share/pwgen_20.c:223
#3  0x08049745 in main (argc=2, argv=0xffbfde14) at /share/pwgen_20.c:360

The string crypt is definitely valid, so I am not sure why it would be dying in fgetspent() ... any suggestions?

EDIT: I should also add that line 223 in the source code is where the first call to fgetspent happens (right below the get_username function call - or line 16 in the original snippet).

This post has been edited by LivingNightmare: 14 May 2012 - 10:33 AM

[simeesta]

Check the file opened correctly ie old != NULL similarly for new. You may need to run the program as root or use sudo as you may not have the permissions to read the file.

This post has been edited by simeesta: 14 May 2012 - 10:39 AM

[vividexstance]

One suggestion would be to check the FILE pointers after you've opened the files too make sure that they opened correctly.

[sepp2k]

Maybe fopen returned null. Did you run the application with root privileges (without them you won't have permission to access /etc/shadow)?

[LivingNightmare]

It looks like you guys were right. Both old and new are set to NULL, but i have no idea why. As for the permission issues, we were told that "The executable pwgen is setuid root, meaning that whenever pwgen is executed (even by a normal user), it will have the full privileges of root instead of the privileges of the normal user", so I don't think it's a permission issue.

[sepp2k]

Are you running pwgen through a remote account? Or did you download it onto your own computer? Because in the latter case, the setuid bit won't be set on the file unless you set it yourself. Downloaded files (over http at least) don't keep their initial permissions.

[Salem_c]

> so I don't think it's a permission issue.
Don't think, find out!

Write something like this to find out WHY the open failed.

old = fopen("/etc/shadow~", "r");
if ( old == NULL ) {
  perror("Unable to open file");
}

It cuts out a hell of a lot of pointless guessing.

[LivingNightmare]

@Salem_c - I had already indicated that both the old and new pointers we're being set to NULL after the function call, but that I wasn't sure why.

@sepp2k - Yes I am copying the file to another directory... but I didn't know that the permissions wouldn't follow. I tried it on the original file, and it seems to work as expected =)

Now all I need to do is find a vulnerability in this code =) - Thanks!

[sepp2k]

LivingNightmare, on 14 May 2012 - 11:49 PM, said:

@Salem_c - I had already indicated that both the old and new pointers we're being set to NULL after the function call, but that I wasn't sure why.

And Salem_c told you how to find out for sure. Or at least how you'll find out for sure the next time since this particular case is solved now.