Sep 192013
 

Knoppix logoSince 2 or 3 years I have been building a Knoppix-based Linux-on-CD distribution for teaching (exercises and exams) at our University. A colleague of mine has written the proper server/client tools for source code submission and evaluation while I have adapted and hardened the system for our needs, based on tons of modifications on the CD and also on the server side, from where a lot of local behavior is controlled by server-side scripts which can dis-/enable the network or USB ports on clients, but which can also shut clients down or verify the media to effectively prevent CD forgery (Its pretty cool to see them students try, so far they never came even remotely close to breaking it).

Now I am supposed to ensure that the system can use sound. It seems some Java-based exercises may contain sound creation and playback in the future. To make sure the system can support new sound chips (which it currently does not) and potentially also new GPUs I tried to hack a new Linux kernel into the system to replace the good old 2.6.32.6, which had the ALSA sound system built in, so I couldn’t update it as a kernel module. Also, updating the whole 6.2.1 thing to Knoppix 7 is just not an option, as it would be far too much work. The kernel update it had to be.

And so the adventure began…

Continue reading »

Feb 012012
 

Tux is dying. Sometimes.There has been a recent [security advisory] about a certain exploit, that affects most Linux Kernels v2.6.39-rc1 and newer, if they contained the upstream patch [198214a7]. The flaw came with a re-enabled mem_write() function and enhancements made to the handling of the /proc/pid/mem permission checks when writing to running programs memory via the facility. It is possible to use this to escalate a users privileges, supposedly all the way up to root. Now that alone is bad enough, but the enhancement has been back-ported by some distributors like RedHat, and hence has also hit CentOS and Scientific Linux even though their kernel versions are <2.6.39-rc1. By now there are kernel updates available to get the problem fixed. In the meantime, there is some sample code available to show wether your specific machine is vulnerable to this kind of /proc/pid/mem hijacking or not. See the source code:

expand/collapse source code
  1. /*
  2.   simple reproducer that tests whether we have commit 198214a7ee50375fa71a65e518341980cfd4b2f0 or not
  3.  */
  4.  
  5. #define _LARGEFILE64_SOURCE
  6. #include &lt;stdio.h&gt;
  7. #include &lt;stdlib.h&gt;
  8. #include &lt;sys/types.h&gt;
  9. #include &lt;sys/stat.h&gt;
  10. #include &lt;fcntl.h&gt;
  11. #include &lt;unistd.h&gt;
  12.  
  13. char *s = "not vulnerable";
  14. char *s2 = "vulnerable";
  15.  
  16. int main(int argc, char **argv)
  17. {
  18.  
  19.   int fd;
  20.   loff_t r;
  21.  
  22.   fd = open("/proc/self/mem", O_RDWR);
  23.   if(fd &lt; 0) {
  24.     perror("open: ");
  25.     goto end;
  26.   }
  27.  
  28.   if(lseek64(fd, (off64_t) &amp;s, SEEK_SET) &lt; 0) {
  29.     perror("lsee64: ");
  30.     goto end;
  31.   }
  32.  
  33.   if(write(fd, &amp;s2, sizeof(s2)) &lt; 0) {
  34.     perror("write: ");
  35.   }
  36.  
  37. end:
  38.   close(fd);
  39.   printf("%s\n", s);
  40. }

You can compile and test the code with GCC:

$ gcc test.c -o test
$ ./test

In case your system is vulnerable, the code will just output “vulnerable”, otherwise it will say “write: : Invalid argument” and “not vulnerable”. In that case your kernel is either too old to have the enhancement or has been fixed already. If your system is vulnerable, updating your Kernel to a fixed version or even downgrading in case there is none available for your distribution is highly recommended.