Project

General

Profile

Bug #4688

getlogin_r shouldn't clobber memory

Added by Robert Mustacchi over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Category:
lib - userland libraries
Start date:
2014-03-15
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

getlogin_r takes a buffer size to describe how large the buffer should be. However, getlogin_r ignores that entirely and just assumes that it is at least LOGIN_NAME_MAX bytes. This means that it will actually corrupt memory and means that calling something like cuserid(3C) can and will corrupt memory. Consider the following sample C program:

#include <unistd.h>
#include <string.h>
#include <stdio.h>

int
main(void)
{
        int ret, i;
        char buf[128];

        memset(buf, 'a', sizeof (buf));

        ret = getlogin_r(buf, 9);
        if (ret != 0) {
                perror("getlogin_r");
                return (1);
        }

        for (i = 0; i < 40; i++)
                printf("%d: %c\\n", i, buf[i]);

        return (0);
}

When run without a fix it produces:

0: r
1: o
2: o
3: t
4: 
5: 
6: 
7: 
8: 
9: 
10: 
11: 
12: 
13: 
14: 
15: 
16: 
17: 
18: 
19: 
20: 
21: 
22: 
23: 
24: 
25: 
26: 
27: 
28: 
29: 
30: 
31: 
32: 
33: a
34: a
35: a
36: a
37: a
38: a
39: a

Note how many more bytes beyond our buffer length have been zeroed out.

The problem is straightforward. The function getl_r_common uses strncpy on the maximum size of a login name. Ironically, it actually checks that the length of the login name fits right before doing so. The solution is to have this function properly honor the length of the buffer passed in.

History

#1

Updated by Robert Mustacchi over 5 years ago

  • Status changed from New to Resolved
#2

Updated by Electric Monk over 5 years ago

git commit 61f9f3e6dc0a66ec5c243562765c1b4a3297e8a4

Author: Robert Mustacchi <rm@joyent.com>

4688 getlogin_r shouldn't clobber memory
Reviewed by: Marcel Telka <marcel.telka@nexenta.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Reviewed by: Gary Mills <gary_mills@fastmail.fm>
Reviewed by: Toomas Soome <tsoome@me.com>
Approved by: Dan McDonald <danmcd@omniti.com>

Also available in: Atom PDF