data disclosure in ioctl sg inquiry

DISCUSSION Andrew Morton 3 participants 4 messages Sep 2, 2007 – Sep 3, 2007

Subsystems (2)

VFS SCSI

lore

Share & tools

lore

Andrew Morton

author

2007-09-02 11:56 UTC #0 lore raw

Begin forwarded message:

Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha <[email protected]>
To: [email protected]
Subject: data disclosure in ioctl sg inquiry

(Please keep me CC'ed. Thanks.)

Hello,

While testing the SG INQUIRY command to a locked hard drive, connected with USB, I noted that the command result included garbage that seemed part of some other's process memory. Like bash functions, command arguments, etc..

I make sure to memset the buffers before running the ioctl, so this seem to be data leaked from the kernel.

Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).

I include the code I used and sample output with data from running processes (or files?).

I can't reproduce this on a firewire connected HDD, but I can with another USB connecte one (not locked).

Regards,
Luciano Rocha

Signature · 2 lines

lfr
0/0

# sda is firewire, unlocked, sdb is usb, locked, and sdc is usb, unlocked
$ ./keytool /dev/sda
Some of the INQUIRY command's response:
00 00 04 02 1f 00 00 00 53 41 4d 53 55 4e 47 20  ........SAMSUNG 
48 44 35 30 31 4c 4a 20 20 20 20 20 20 20 20 20  HD501LJ         
43 52 31 30 00 00 00 00 00 00 00 00 00 00 00 00  CR10............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 1d c0 ff ff ff c1 ff  ................
INQUIRY duration=3 millisecs, resid=0
# always the same output for sda

$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32  3.AA....#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08  340.....H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72  ....Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20   --exclude .svn 
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 2e 70 6c 20 73 79 6e 63 20 78 70 74  3.AA.pl sync xpt
6f 20 7a 62 72 20 7c 20 6c 65 73 73 00 4c 11 08  o zbr | less.L..
f0 c8 11 08 11 00 00 00 23 31 31 38 38 32 32 32  ........#1188222
33 34 30 00 11 00 00 00 68 c0 11 08 48 c0 11 08  340.....h...H...
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 21 00 00 00 10 2f 12 08 18 2f 12 08  3.AA!..../.../..
00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00  ............$...
01 00 00 00 19 00 00 00 98 1b 12 08 6d 65 2f 6c  ............me/l
75 63 69 61 6e 6f 00 7d 22 00 10 08 19 00 00 00  uciano.}".......
INQUIRY duration=0 millisecs, resid=60

$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35  ....#...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20  00BB-00RDA0     
32 30 2e 30 06 7b 25 07 08 3a 11 08 40 e9 12 08  20.0.{%..:..@...
10 3a 11 08 3b 00 00 00 28 f8 11 08 11 00 00 00  .:..;...(.......
df df df df df df df df 30 00 00 00 11 00 00 00  ........0.......
80 54 13 08 18 20 00 00 00 00 00 00 19 00 00 00  .T... ..........
INQUIRY duration=0 millisecs, resid=56
$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35  ....#...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20  00BB-00RDA0     
32 30 2e 30 06 7b 25 07 73 73 68 20 70 00 11 45  20.0.{%.ssh p..E
00 00 00 00 11 00 00 00 23 31 31 38 38 32 30 32  ........#1188202
34 32 30 00 11 00 00 00 58 e0 12 08 38 e0 12 08  420.....X...8...
00 00 00 00 21 00 00 00 63 64 20 2f 70 72 69 76  ....!...cd /priv
INQUIRY duration=3 millisecs, resid=56

...

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>

#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

#include <error.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <scsi/sg.h>
#include <linux/hdreg.h>

static void dump(const unsigned char *b, int l)

{
	int i;

	while (l) {
		for (i = 0; i < l && i < 16; ++i)
			printf("%02x ", b[i]);
		printf(" ");
		for (i = 0; i < l && i < 16; ++i) {
			if (b[i] < 0x20 || b[i] > 0x7e) {
				printf(".");
			} else {
				printf("%c", b[i]);
			}
		}
		printf("\n");
		b += i;
		l -= i;
	}
}

enum { INQ_REPLY_LEN = 96, INQ_CMD_CODE = 0x12, INQ_CMD_LEN = 6 };

static void hdd_ident(const char *device)

{
	unsigned char inqCmdBlk[INQ_CMD_LEN] = {
		INQ_CMD_CODE, 0, 0, 0, INQ_REPLY_LEN, 0
	};
	unsigned char inqBuff[INQ_REPLY_LEN];
	unsigned char sense_buffer[32];
	union {
		struct hd_driveid drv;
		sg_io_hdr_t sg;
	} u;
	int fd;
	int k;

	fd = open(device, O_RDONLY);
	if (fd < 0) error(1, errno, "couldn't open %s", device);

	if (ioctl(fd, HDIO_GET_IDENTITY, &u.drv) >= 0) {
		printf("serial: '%.*s'\n", sizeof u.drv.serial_no,
				u.drv.serial_no);
		printf("model:  '%.*s'\n", sizeof u.drv.model, u.drv.model);
	} else if (ioctl(fd, SG_GET_VERSION_NUM, &k) < 0 || k < 30000) {
		error(1, 0, "device %s isn't an IDE or SCSI device", device);
	} else {
		memset(&u.sg, 0, sizeof u.sg);
		memset(inqBuff, 0, sizeof inqBuff);
		memset(sense_buffer, 0, sizeof sense_buffer);
		u.sg.interface_id = 'S';
		u.sg.cmd_len = sizeof(inqCmdBlk);
		/* u.sg.iovec_count = 0; */  /* memset takes care of this */
		u.sg.mx_sb_len = sizeof(sense_buffer);
		u.sg.dxfer_direction = SG_DXFER_FROM_DEV;
		u.sg.dxfer_len = INQ_REPLY_LEN;
		u.sg.dxferp = inqBuff;
		u.sg.cmdp = inqCmdBlk;
		u.sg.sbp = sense_buffer;
		u.sg.timeout = 20000;     /* 20000 millisecs == 20 seconds */
		/* u.sg.flags = 0; */     /* take defaults: indirect IO, etc */
		/* u.sg.pack_id = 0; */
		/* u.sg.usr_ptr = NULL; */

		if (ioctl(fd, SG_IO, &u.sg) < 0)
			error(1, errno, "couldn't inquire %s", device);

		/* now for the error processing */
		if ((u.sg.info & SG_INFO_OK_MASK) != SG_INFO_OK) {
			if (u.sg.sb_len_wr > 0) {
				printf("INQUIRY sense data: ");
				for (k = 0; k < u.sg.sb_len_wr; ++k) {
					if ((k > 0) && (0 == (k % 10)))
						printf("\n  ");
					printf("0x%02x ", sense_buffer[k]);
				}
				printf("\n");
			}
			if (u.sg.masked_status)
				printf("INQUIRY SCSI status=0x%x\n",
						u.sg.status);
			if (u.sg.host_status)
				printf("INQUIRY host_status=0x%x\n",
						u.sg.host_status);
			if (u.sg.driver_status)
				printf("INQUIRY driver_status=0x%x\n",
						u.sg.driver_status);
		} else {  /* assume INQUIRY response is present */
			printf("Some of the INQUIRY command's response:\n");
			dump(inqBuff, sizeof inqBuff);
			printf("INQUIRY duration=%u millisecs, resid=%d\n",
					u.sg.duration, u.sg.resid);
		}
	}
	close(fd);

}

int main(int argc, char *argv[])

{
	char *device;
	char *eeprom;

	while (*++argv) {
		hdd_ident(*argv);
	}
	return 0;
}

FUJITA Tomonori

2007-09-02 14:15 UTC #1 lore raw

Quoted 23 lines · On Sun, 2 Sep 2007 04:56:01 -0700 Andrew Morton <[email protected]>…

Begin forwarded message:
Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha <[email protected]>
To: [email protected]
Subject: data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected with USB, I noted that the command result included garbage that seemed part of some other's process memory. Like bash functions, command arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem to be data leaked from the kernel.

Quoted 8 lines

Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).
I include the code I used and sample output with data from running processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with another USB connecte one (not locked).

$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32  3.AA....#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08  340.....H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72  ....Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20   --exclude .svn 
INQUIRY duration=3 millisecs, resid=60

Note that resid is 60. So, in your case, only the first 36 bytes are valid. But I guess that it's not good to leak random kernel data to user-space.

Can you try this patch?

---

Quoted 1 line

From 2529dbda52ac2302eab9838910d59e13dedeb3bd Mon Sep 17 00:00:00 2001

From: FUJITA Tomonori <[email protected]>
Date: Sun, 2 Sep 2007 13:32:33 +0100
Subject: [PATCH] bio_copy_user use zeroed pages

bio_uncopy_user copies garbage to user-space buffer when the actual transferred length is shorter than dxfer_len.

Signed-off-by FUJITA Tomonori <[email protected]>

---
 fs/bio.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

fs/bio.c +6 -1

index 29a44c1..26a7669 100644
@@ -550,11 +550,16 @@ struct bio *bio_copy_user(struct request_queue *q, unsigned long uaddr,
 	ret = 0;
 	while (len) {
 		unsigned int bytes = PAGE_SIZE;
+		gfp_t mask;
 
 		if (bytes > len)
 			bytes = len;
 
-		page = alloc_page(q->bounce_gfp | GFP_KERNEL);
+		mask = q->bounce_gfp | GFP_KERNEL;
+		if (write_to_vm)
+			mask |= __GFP_ZERO;
+
+		page = alloc_page(mask);
 		if (!page) {
 			ret = -ENOMEM;
 			break;

Signature · 1 line

1.5.2.4

Douglas Gilbert

2007-09-03 17:01 UTC #2 lore raw

Quoted 76 lines · FUJITA Tomonori

Quoted 22 lines · On Sun, 2 Sep 2007 04:56:01 -0700 Andrew Morton <[email protected]>…
Begin forwarded message:
Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha <[email protected]>
To: [email protected]
Subject: data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected with USB, I noted that the command result included garbage that seemed part of some other's process memory. Like bash functions, command arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem to be data leaked from the kernel.
Quoted 8 lines
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).
I include the code I used and sample output with data from running processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with another USB connecte one (not locked).
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32  3.AA....#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08  340.....H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72  ....Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20   --exclude .svn 
INQUIRY duration=3 millisecs, resid=60
Note that resid is 60. So, in your case, only the first 36 bytes are valid. But I guess that it's not good to leak random kernel data to user-space.
Can you try this patch?
---
Quoted 1 line
From 2529dbda52ac2302eab9838910d59e13dedeb3bd Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[email protected]>
Date: Sun, 2 Sep 2007 13:32:33 +0100
Subject: [PATCH] bio_copy_user use zeroed pages
bio_uncopy_user copies garbage to user-space buffer when the actual transferred length is shorter than dxfer_len.
Signed-off-by FUJITA Tomonori <[email protected]>
---
 fs/bio.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
fs/bio.c +1 -0
index 29a44c1..26a7669 100644
@@ -550,11 +550,16 @@ struct bio *bio_copy_user(struct request_queue *q, unsigned long uaddr,
 	ret = 0;
 	while (len) {
 		unsigned int bytes = PAGE_SIZE;
+		gfp_t mask;
 
 		if (bytes > len)
 			bytes = len;

fs/bio.c struct bio *bio_copy_user(struct request_queue *q, unsigned long uaddr, · line 565

Quoted 10 lines

fs/bio.c +5 -1

 
-		page = alloc_page(q->bounce_gfp | GFP_KERNEL);
+		mask = q->bounce_gfp | GFP_KERNEL;
+		if (write_to_vm)
+			mask |= __GFP_ZERO;
+
+		page = alloc_page(mask);
 		if (!page) {
 			ret = -ENOMEM;
 			break;

Hello folks. This has been known about (or variations of it) for some time. The design approach has been:
- if the uid of the app is 0 (i.e. root) then we take the fast approach (i.e. don't zero intermediate buffers) as root can see the whole of ram anyway
- if the uid of the app is !=0 (i.e. a non-root user) then zero intermediate buffers (and slow things down a bit)

Doug Gilbert

FUJITA Tomonori

2007-09-03 17:13 UTC #3 lore raw

Quoted 88 lines · On Mon, 03 Sep 2007 13:00:43 -0400 Douglas Gilbert <[email protected]> wrote:

Quoted 76 lines · FUJITA Tomonori
Quoted 22 lines · On Sun, 2 Sep 2007 04:56:01 -0700 Andrew Morton <[email protected]>…
Begin forwarded message:
Date: Mon, 27 Aug 2007 15:01:33 +0100
From: Luciano Rocha <[email protected]>
To: [email protected]
Subject: data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected with USB, I noted that the command result included garbage that seemed part of some other's process memory. Like bash functions, command arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem to be data leaked from the kernel.
Quoted 8 lines
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).
I include the code I used and sample output with data from running processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with another USB connecte one (not locked).
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53  ........MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20  TM3250820A      
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32  3.AA....#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08  340.....H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72  ....Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20   --exclude .svn 
INQUIRY duration=3 millisecs, resid=60
Note that resid is 60. So, in your case, only the first 36 bytes are valid. But I guess that it's not good to leak random kernel data to user-space.
Can you try this patch?
---
Quoted 1 line
From 2529dbda52ac2302eab9838910d59e13dedeb3bd Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[email protected]>
Date: Sun, 2 Sep 2007 13:32:33 +0100
Subject: [PATCH] bio_copy_user use zeroed pages
bio_uncopy_user copies garbage to user-space buffer when the actual transferred length is shorter than dxfer_len.
Signed-off-by FUJITA Tomonori <[email protected]>
---
 fs/bio.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
fs/bio.c +1 -0
index 29a44c1..26a7669 100644
@@ -550,11 +550,16 @@ struct bio *bio_copy_user(struct request_queue *q, unsigned long uaddr,
 	ret = 0;
 	while (len) {
 		unsigned int bytes = PAGE_SIZE;
+		gfp_t mask;
 
 		if (bytes > len)
 			bytes = len;
fs/bio.c struct bio *bio_copy_user(struct request_queue *q, unsigned long uaddr, · line 565
Quoted 10 lines
fs/bio.c +5 -1
 
-		page = alloc_page(q->bounce_gfp | GFP_KERNEL);
+		mask = q->bounce_gfp | GFP_KERNEL;
+		if (write_to_vm)
+			mask |= __GFP_ZERO;
+
+		page = alloc_page(mask);
 		if (!page) {
 			ret = -ENOMEM;
 			break;

Quoted 7 lines

Hello folks. This has been known about (or variations of it) for some time. The design approach has been:
- if the uid of the app is 0 (i.e. root) then we take the fast approach (i.e. don't zero intermediate buffers) as root can see the whole of ram anyway
- if the uid of the app is !=0 (i.e. a non-root user) then zero intermediate buffers (and slow things down a bit)

It's tree for your sg, but I think that he uses block sg code and it doesn't do such thing.