Bug#876541: [PATCH] Patch for bug 876541

[Thomas Kremer]

found 876541 0.2.3h+dfsg-1
tag 876541 patch

thanks.


And here is your patch.

Questions:
 - This exact version of xul-ext-sieve actually once worked for me. Has
there been a feature reduction in the underlying javascript engine?
 - Will this patch be implemented? In stable?
 - [some self-censored question about anonymous maintainer lists'
reaction patterns]


Yours
Thomas Kremer


-- 
OpenPGP Key ID: 0x6BFFE5CF3C7720398928CE741F2DAE97486A60BF

--- /usr/share/xul-ext/sieve/chrome/chromeFiles/content/editor/SieveFilterEditor.js.orig	2015-08-09 21:40:50.0 +0200
+++ /usr/share/xul-ext/sieve/chrome/chromeFiles/content/editor/SieveFilterEditor.js	2018-01-31 23:34:47.189097792 +0100
@@ -127,14 +127,9 @@
   
   var hash = ch.finish(false);  
   
-  // return the two-digit hexadecimal code for a byte  
-  function toHexString(charCode)  
-  {  
-return ("0" + charCode.toString(16)).slice(-2);  
-  }  
-  
   // convert the binary hash data to a hex string.  
-  return [toHexString(hash.charCodeAt(i)) for (i in hash)].join("");  
+  return Array.from(hash, 
+  function (cur, idx) { return ("0" + hash.charCodeAt(idx).toString(16)).slice(-2); } ).join(""); 
 }
 
 SieveFilterEditor.prototype.onGetScriptResponse

Bug#868190: gatling: -u is silently ignored if is a username rather than a numeric user id

[Thomas Kremer]

Hi,

I tracked down the offending line that lead to the failure of reporting
a name lookup failure in the chroot, see attached patch.
I haven't had the time to test the patch though.

The issue is already fixed in upstream's ver. 0.15.

The name lookup failure itself is due to the username being looked up
twice, once before chrooting and once after chrooting (a feature to have
CGIs unable to interfere with the main server process by using different
uids, though a little confusing). Providing a /var/www/etc/passwd with
the user is however not enough, because Debian's gatling is linked with
glibc, which uses libnss. Providing
/var/www/lib/x86_64-linux-gnu/{libnss_compat.so.2,libnsl.so.1} to the
chroot can solve this.

In a related note, I suggest to make use of start-stop-daemon's "-d"
option to give the user an option (in /etc/default/gatling) to specify
the served directory without needing to chroot into it (as a chroot does
imply some restrictions on what kind of CGI applications can be
implemented).


Yours
Thomas


-- 
OpenPGP Key ID: 0x6BFFE5CF3C7720398928CE741F2DAE97486A60BF
--- gatling-0.13/gatling.c.orig	2017-07-25 03:25:00.278571785 +0200
+++ gatling-0.13/gatling.c	2017-07-25 03:25:59.666866276 +0200
@@ -1382,7 +1382,7 @@
 	  buffer fsb;
 #ifndef __MINGW32__
 	  if (chroot_to) { chdir(chroot_to); chroot(chroot_to); }
-	  prepare_switch_uid(new_uid);
+	  if (prepare_switch_uid(new_uid)==-1) panic("switch_uid failed");
 #endif
 	  if (!io_readfile(&savedir,".")) panic("open()");
 	  buffer_init(&fsb,(void*)read,forksock[1],fsbuf,sizeof fsbuf);

Bug#868190: gatling: -u is silently ignored if is a username rather than a numeric user id

[Thomas Kremer]

Package: gatling
Version: 0.13-6+b1
Justification: 5.b
Severity: serious
Tags: security

Dear Maintainers,

Dropping privileges fails silently if -u is used with a username rather
than a numeric user id. Such usage is even recommended in both the
manpage and /etc/default/gatling. Any CGI script is consequently run as
root (though chrooted - but a chroot is not a jail for root processes).

Concretely, requesting "http://127.0.0.1/test.cgi";, from the following
server will run /var/www/default/test.cgi as root:
  gatling -v -D -S -F -U -u nobody -c /var/www -C "^/test\\.cgi$"

While this server will run it as user nobody:
  gatling -v -D -S -F -U -u 65534 -c /var/www -C "^/test\\.cgi$"

Note that "-u nobody" is the recommended usage in manpage and
/etc/default/gatling.

Reproducing this is a bit cumbersome:

  # apt-get install busybox-static
  # mkdir /var/www/.bin
  # cp -al /bin/busybox /var/www/.bin/
  # cat > /var/www/default/test.cgi << EOF
#!/.bin/busybox sh

cat << EOHDR
Status: 200
Content-Type: text/plain; charset=UTF-8

Hallo Welt
==
EOHDR

/.bin/busybox id

echo "---"
cat /secret.txt
echo "---"

EOF
  # echo "A SECRET HAS BEEN UNVEILED" > /var/www/secret.txt
  # chmod 0600 /var/www/secret.txt
  # chmod 0755 /var/www/default/test.cgi
  # touch /var/www/default/.proxy
  # gatling -v -D -S -F -U -u nobody -c /var/www -C "^/test\\.cgi$"

  $ curl "http://127.0.0.1/test.cgi";

The result shows that the CGI process is run with uid=0 and clearly has
read access to /var/www/secret.txt.

As is common knowledge, by mounting proc inside the chroot and accessing
/proc/1/root/, the process can then escape the chroot.

Note that using busybox is only one way to get non-compiled CGIs work in
a chroot in the first place and is not a requirement for the bug to be
exploited. The only requirement is a security hole in a CGI (which is,
after all, quite common, which is why webservers drop privileges in the
first place).

I suggest the following procedures, in that order:
- Fixing manpage and /etc/default/gatling to match actual behaviour
- making gatling throw an error if the uid is non-numeric
- implementing actual user name lookup and then reverting the above two.


Yours
Thomas Kremer


-- System Information:
Debian Release: 8.8
  APT prefers oldstable
  APT policy: (700, 'oldstable'), (500, 'oldoldstable'), (450,
'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gatling depends on:
ii  libc6   2.19-18+deb8u10
ii  libmbedcrypto0  2.4.2-1
ii  libmbedtls102.4.2-1
ii  libmbedx509-0   2.4.2-1
ii  libowfat0   0.29-4
ii  libssl1.1   1.1.0f-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

gatling recommends no packages.

gatling suggests no packages.

-- no debconf information