Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
On Sat, 2014-12-20 at 02:10 -0200, Henrique de Moraes Holschuh wrote: IMHO, the suggested wording does get the point across that whomever wants to use RPATH/RUNPATH must be prepared to defend its use with strong technical reasons. Exactly. Without it I was concerned this would tacitly condone use of RPATH/RUNPATH and that's counterproductive. (At the same time there seem to be cases where complete avoidance is difficult hence the escape clause). This part looks good. IMO, it is too weak. This is about introducing security hazards, so... weak is a feature :) My suggested text is not perfect. My aim is to seed uncontroversial text that will educate, delimit bad practice, serve as a basis for further refinement. Perfect has been the enemy of good here. And in fact, I'd add: Packages are not allowed to create *and* execute libraries or executables with unsafe RPATH or RUNPATH at any time, not even during their build process. But actually Package maintainers should not make or run dangerous stuff? Agreed -- and also seems uncontroversial. Although I think you mean or not and? Perhaps neither/nor to kill any ambiguity: 8.7 RUNPATH and RPATH Libraries and executables should not define RPATH or RUNPATH unless absolutely necessary. Those that do should ensure that relative paths or paths that traverse insecure directories (eg /tmp or /var/tmp) are not included. This is to prevent an executable from loading a library from an untrusted location. (This should include the corner cases whereby the path list starts or ends with a colon, or includes two consecutive colons). Packages should neither create nor execute libraries or executables with unsafe RPATH or RUNPATH at any time, not even during their build process. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH
Package: debian-policy Severity: important Tags: patch Dear Maintainer, The existing policy does not specify that the RPATH or RUNPATH (if present) should not contain relative paths or paths that traverse dangerous (eg world writable) directories. There is some discussion of this on the OSS-security list starting at: http://seclists.org/oss-sec/2014/q4/761 Example bugs that could be avoided with such a policy: https://bugs.debian.org/754278 https://bugs.debian.org/759868 See also: https://bugs.debian.org/458824 https://bugs.debian.org/555982 There is some good discussion in these last two reports but they are both stale (5 years). I suspect that this is because the scope of these proposals is quite broad. Therefore I'd like to propose a (hopefully uncontraversial) paragraph that addresses at least the security concern and that may provide a base for further refinements in the spirit of #458824 and #555982 as well as a raison d'etre for a future lintian check to help avoid these security exposures. (There is an existing check for RPATH in lintian (binary-or-shlib-defines-rpath) but it is only Certainty: possible due to possible caveats. Relative RPATH/RUNPATH on the other hand is slam-dunk certain). 8.7 RUNPATH and RPATH Libraries and executables should not define RPATH or RUNPATH unless absolutely necessary. Those that do should ensure that relative paths or paths that traverse insecure directories (eg /tmp or /var/tmp) are not included. This is to prevent an executable from loading a library from an untrusted location. (This should include the corner cases whereby the path list starts or ends with a colon, or includes two consecutive colons). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771382: Triaged crashes
All crashes are due to a nil dereference in line 137 of execute.c.
Shortest test case to date:
$ printf '1L1\n+11\n' | bc
(standard_in) 1: illegal character: L
(standard_in) 1: syntax error
Segmentation fault (core dumped)
$ gdb ./bc ./core
[...]
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00404c7a in execute () at execute.c:137
137 pc.pc_addr = gp-l_adrs[l_off];
(gdb) bt
#0 0x00404c7a in execute () at execute.c:137
#1 0x00407f15 in run_code () at util.c:309
#2 0x00401cf6 in yyparse () at bc.y:135
#3 0x00401203 in main (argc=1, argv=0x7fff0e5cc9d8) at main.c:259
(gdb) list
132 || (inst == 'Z' !c_code)) {
133 gp = functions[pc.pc_func].f_label;
134 l_gp = label_num BC_LABEL_LOG;
135 l_off = label_num % BC_LABEL_GROUP;
136 while (l_gp-- 0) gp = gp-l_next;
137 pc.pc_addr = gp-l_adrs[l_off];
138 }
139 break;
140
141 case 'C' : /* Call a function. */
(gdb) print pc.pc_func
$1 = 0
(gdb) print functions[pc.pc_func]
$2 = {f_defined = 0 '\000', f_void = 0 '\000', f_body = 0xfca730 1B\001,
f_body_size = 1024, f_code_size = 11, f_label = 0x0, f_params = 0x0, f_autos =
0x0}
(gdb) print gp
$1 = (bc_label_group *) 0x0
(gdb)
So... it seems like the lexer/parser is leaving junk on the state
machine input after the syntax error/illegal character error which then
tries branch instruction to somewhere that cannot exist.
Tempting to say fail hard on the first error but this wouldn't be
appropriate in the interactive usage scenario and the crash also occurs
there.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771382: bc: Crash on bad input
Package: bc Version: 1.06.95-8ubuntu1 Severity: normal Dear Maintainer, Fuzzed crashes using afl (not likely to cross a trust boundary so not reporting as a security bug). Test cases attached/below. begin 660 crash.tgz M'XL(`(050``^V:38^30!C'.7@P1+^`)[)+J`[#\,PE)N;/[!3]$=*VM MUK26=4\F^D]^24\.D`7.K4O`=UA-_/_]=6D@[-]#?/RS!9Y\7LW+E7F$)* MIIXC'D?;SPT.13%/(L8ID0XC%@GI.)^+ZOF:W3KSW/^?QQO2\4Y\_4B;5 M_,^OLW(6B(?%_$-%!;K27DDY:-PNIF^UR$J[?K[*HSQCE5R?LR/QS7L^_ MFGPBH8_XIOX+'__6/W8?G\!W1%;D^[[_Q-]!Y81^#7UIP`:_TSL]W^Z MF*\H7V+C/HXVW_J/)?1O#?!*W_T\;_`/Y;@^Z_W.]_OI[?S-)J`4CVWR1 MO9=QNCNOQ24P'\3U/XWL1_^6X;N?WPJ_LL^8_2)_X3\WPB;^#^%_W:BU_\' M__K_[C/*?\)XK_JO^1_YM!]W_[W:'C[3*A+1@OL`\1G3_V2#^,RZV_(_1 M_S-(6__[UWZD_N2W#-D`#:@Y_^TX[\[?A/?;HD/\GHCRO]%_`?Q-L_/_6 M0?J4;_[M7!@R@^W]@_Z^M_Y,^8_2J_^_$6K_?I_EJ+[GSR_3\._TVP M;_\?_MN#[O]N_2]3L9/_]TD`3O?_FOI?!?ZJ_H\%P7\3/*+Y?/]\IY8/@ MN_/,^4'5R_GFFI)$/X1ZO.=)^.G0_\8T!G=__3D_G]:[?\'G?*`/OO_$OF_ M$[B_U8%@/AO$7K_/QJH_\_1_Q^(VO]7OG_9W`)8^O\;_MN!'O]'#^#^_QCU MOT\=O_/WS0!$/\M0O?_0/P?HO\?PW\3U/'__K_EJ+G_[O[_P/F_[C_WP@! E7:J'\GVAK0!OU9A+PT``//_`'SANH`%`` ` end -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-40-generic (SMP w/8 CPU cores) 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 bc depends on: ii libc6 2.19-0ubuntu6.3 ii libreadline6 6.3-4ubuntu2 bc recommends no packages. bc 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
