[svlug] Serious NTP security holes
Rick Moen
rick at svlug.org
Tue Dec 23 02:23:03 PST 2014
Jason Fritcher wrote:
> Achieving a remote code execution means they're in the box
Well, hold a second. First of all, nobody's achieved remote code execution
in this case. ICSA-14-353-01 says merely the familiar handwave about how a
remote attacker might some day figure out how to send a carefully crafted
package that might somehow 'potentially allow malicious code to be executed
with the privilege level of the ntpd process'. Which you may have noticed
was part of my point, that this like all similar advisories needs to be read
attentively enough so that you are aware that the 'remote code execution'
warning is anticipatory, and is speculative about what might or might not
eventually also turn up.
Eventually (if at all), not today. Which was a key part of my point about
reading these warnings in correct perspective. You don't have anything
against proper perspective, do you?
I most certainly did not advise people offering NTP service ot proper
networks to ignore the bug and its code fixes. Rather the contrary.
> ...and it's only a matter of time before a local privilege escalation is
> found...
As one of Moen's Laws of Security puts it, "it's always easier to break in
from inside', true.
> especially in light of CVE-2014-9322.
CVE-2014-9322's a pretty serious locally-exploitable kernel problem,
absolutely. By the time someone figures out how to eploit ICSA-14-353-01,
though, I'm betting that kernels that fix CVE-2014-9322 will be old hat,
given that the package revisions started emerging around the 19th. I'm
betting that writeable kernel stacks capable of supporting IRET instructions
will be long gone by then, and they're pretty rare already. (Thus, it may
be pretty difficult to use CVE-2014-9322 for escalation even with no
mitigations whatsoever.)
More information about the svlug
mailing list