Package: bcron Version: 0.09-12 Severity: normal Tags: upstream Dear Maintainer,
I think I have found a security breach in bcron. Bcron-exec program does not close its file descriptors when does fork()/exec() to run scheduled jobs. When used in untrusted environment such as shared hosting, it is possible for one user to send spam from neighbour user's accounts or read other's cron job stdout. In deeper details. If any user's program runs through cron and generates some output to stdout/stderr, cron must send its output to owner's e-mail. Bcron uses start_slot() function to create a temp file, write e-mail message headers in there to prepare this mail to be sent and then does fork/exec to run scheduled task and redirects its stdout/stderr to this particular file. After this task done its work, bcron in end_slot() compares the length of temp file with stored length of empty temp file with only headers filled in and if they differ, end_slot() runs sendmail to deliver this message. start_slot() calls forkexec_slot() to fork and forkexec_slot() calls exec_cmd() to exec corresponding task. But before calling execv() it must close all open fds execpt stdin/stdout/stderr. Unfortunatelly, there is no such code in exec_cmd(). If one creates 2 tasks and runs them simultaneously using bcron, the following situation occurs: 1. First task (cron1.sh): root@debian:~# lsof -p 14230 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cron1.sh 14230 root cwd DIR 254,0 4096 902 /root cron1.sh 14230 root rtd DIR 254,0 4096 2 / cron1.sh 14230 root txt REG 254,0 106920 624 /bin/dash cron1.sh 14230 root mem REG 254,0 1583120 732 /lib/x86_64-linux-gnu/libc-2.13.so cron1.sh 14230 root mem REG 254,0 136936 977 /lib/x86_64-linux-gnu/ld-2.13.so cron1.sh 14230 root 0u CHR 1,3 0t0 1199 /dev/null cron1.sh 14230 root 1u REG 0,17 479453 22716 /tmp/bcron.14096.1346752020.105007 (deleted) cron1.sh 14230 root 2u REG 0,17 479453 22716 /tmp/bcron.14096.1346752020.105007 (deleted) cron1.sh 14230 root 3r FIFO 0,8 0t0 55752 pipe cron1.sh 14230 root 10r REG 254,0 45 115 /root/cron1.sh 2. second task (cron2.sh): root@debian:~# lsof -p 14231 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cron2.sh 14231 root cwd DIR 254,0 4096 902 /root cron2.sh 14231 root rtd DIR 254,0 4096 2 / cron2.sh 14231 root txt REG 254,0 106920 624 /bin/dash cron2.sh 14231 root mem REG 254,0 1583120 732 /lib/x86_64-linux-gnu/libc-2.13.so cron2.sh 14231 root mem REG 254,0 136936 977 /lib/x86_64-linux-gnu/ld-2.13.so cron2.sh 14231 root 0u CHR 1,3 0t0 1199 /dev/null cron2.sh 14231 root 1u REG 0,17 316908 22717 /tmp/bcron.14096.1346752020.105958 (deleted) cron2.sh 14231 root 2u REG 0,17 316908 22717 /tmp/bcron.14096.1346752020.105958 (deleted) cron2.sh 14231 root 3r FIFO 0,8 0t0 44757 pipe cron2.sh 14231 root 6u REG 0,17 318938 22716 /tmp/bcron.14096.1346752020.105007 (deleted) cron2.sh 14231 root 10r REG 254,0 45 112 /root/cron2.sh Notice fd #6 is temp file created for gathering output of cron1.sh but cron2.sh has access to it and may overwrite it with its own content. And this message would be sent from cron1 while cron1 never generated it. Speaking about shared hosting environment, it is possible for malicious user to send spam without any traces showing this spam was sent from his/her account. I'm going to attach path fixing this issue after it is tested and considered stable. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bcron depends on: ii libbg1 1.106-1 ii libc6 2.13-35 Versions of packages bcron recommends: ii bcron-run 0.09-12 ii postfix [mail-transport-agent] 2.9.3-2.1 ii runit 2.1.1-6.2 ii ucspi-unix 0.36-4 bcron suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
