search for: ld_profile_output

...d various versions of libc and found a handful of weak points where the value of an enviroment variable is trusted more than necessary. Variable Impact NLSPATH can read arbitrary file LANGUAGE, LANG, LC_* dtto (if the value starts with a sufficient number of "../") TZ dtto (../) LD_PROFILE_OUTPUT can overwrite arbitrary file (not verified) Quite a lot of harm can be caused even with read-only access. Think of getting read access to /dev/*, esp. /dev/mem and /dev/port (welcome to the world of PC hardware <g>), /proc/kmsg or /proc/*/fd/*. Affected versions chart Ver./Var. NLSP...

Hi, Standard approach to profiling dynamically loaded libraries with gprof doesn't seem to work with LLVM: export LD_PROFILE=Mylib.so export LD_PROFILE_OUTPUT=. make ENABLE_PROFILING=1 // compiling my project opt -load Profile/Mylib.so -options... but no Mylib.so.profile (or gmon.out) is produced. Profiling libc.so.6 usage by "ls -l", however, works fine. Could anyone explain me what am I doing wrong? Thx. Domagoj Other possibly re...

...your firewall? First of all, it is quite unlikely the bug is remotely exploitable (but it is certainly possible: for instance, the telnet protocol allows the client to set arbitrary enviroment variables, and some old versions of telnetd honored the settings carelessly). Second, the bugs (save from LD_PROFILE_OUTPUT which is much more dangerous) can be abused to crash the system (read /dev/flaky_device), annihilate kernel messages (read /dev/kmsg), or corrupt open data streams (read /proc/1234/fd/0), one can hardly steal data or modify them in any predictible way. ad [2]: The proper precaution is to fix libc...