TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Bash bug: the other two RCEs, or how we chipped away at the original fix

152 点作者 stakent超过 10 年前

8 条评论

bjornsing超过 10 年前
I&#x27;ll say it again [1]: Thank God for Florian Weimer! And after this excellent post I&#x27;m adding Michal Zalewski to that list.<p>1. <a href="https://news.ycombinator.com/item?id=8378515" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8378515</a>
评论 #8395649 未加载
userbinator超过 10 年前
I think there is a fairly convincing argument here that a lot of these bugs might not have occurred if Bash used a hand-written, recursive-descent parser instead of a Yacc autogenerated one:<p>- The original ShellShock: Reused the general parsing&#x2F;execution function for the subset task of evaluating a function definition. A hand-written parser would likely have this isolated to its own function. With a Yacc parser, there is neither an obvious nor easy way to call directly into the parser to parse a &quot;nonterminal&quot;.<p>- The ones in the article having to do with error handling: traditionally, error handing in autogenerated parsers has been more difficult and Yacc is no exception. This is related to the first point in that a function for only parsing the function definitions would never execute its input, even upon encountering an error; the usual abort behaviour means the parser stack unwinds until the original caller - in this case the code parsing environment variables for function definitions - recognises the error, outputs an error message, and in this case, ignores the definition.<p>- The operation of a recursive-descent parser is simpler to trace through manually since each piece of the grammar is logically broken into separate functions, making it easier to audit than the more opaque flow of a Yacc one.
Animats超过 10 年前
The real problem is that Bash has a huge attack surface and isn&#x27;t written with security in mind. With the number of new exploits found here without too much effort, there are almost certainly more yet to be found. (Or already known to attackers.)
评论 #8396703 未加载
评论 #8397557 未加载
IshKebab超过 10 年前
Well now that they&#x27;ve found these 4 highly worrying bugs and fixed them I&#x27;m sure the rest of the totally sane bash code is safe. Right guys?
评论 #8397808 未加载
ck2超过 10 年前
I am still showing segfault on a fully patched (through #20) copy of Bash 3.0<p><pre><code> bash -c &quot;f(){ x(){ _;};x(){ _;}&lt;&lt;a;}&quot; Segmentation fault (core dumped)</code></pre>
danielweber超过 10 年前
Bash is doing a crazy about of stuff under-the-hood. I spent a lot of time over the weekend inside gdb trying to trace down one weird behavior that appeared when I added a single printf(), and I got taken on a very wild ride.<p>(It wasn&#x27;t necessarily a security issue, but I figured I&#x27;d go exploring to learn some bash internals.)
javanix超过 10 年前
Red Hat&#x27;s communication on their distribution of Florian&#x27;s patch was sorely lacking, especially after <a href="http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficial-patch-now.html" rel="nofollow">http:&#x2F;&#x2F;lcamtuf.blogspot.com&#x2F;2014&#x2F;09&#x2F;bash-bug-apply-unofficia...</a>.<p>It was in no way clear that Red Hat&#x27;s second release included Florian&#x27;s fixes - I found out from Mark Cox&#x27;s post on this Twitter thread - <a href="https://twitter.com/lcamtuf/status/516297412579581952" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;lcamtuf&#x2F;status&#x2F;516297412579581952</a>
rurban超过 10 年前
bashcheck <a href="https://github.com/hannob/bashcheck/blob/master/bashcheck" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hannob&#x2F;bashcheck&#x2F;blob&#x2F;master&#x2F;bashcheck</a> includes now also tests for the last 2 lcamtuf bugs, so it tests now for 6 known vulns from this shellshock series, plus a general test for variable function parser safety.