81–90 of 254 posts
Earlier quoted context omitted.
[deleted]
You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'. Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
Earlier quoted context omitted.
The upstream patch is dated "Mon, 21 Jan 2013". Does this affect Redhat and Debian because they use older glibc versions and didn't backport this fix?
yes
Earlier quoted context omitted.
Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_... . Note that this is a HEAD link, so if there are changes after I post this they should appear. I don't claim to have spotted the suspicious code (it's not ... super-accessible), just wanted to provide a link to the file in question.
I'm not fully though my morning bootup process and so not really ready to grok this but, can anyone give a quick summary of why gethostbyname() needs to hit the heap at all, let alone with a realloc call? There's a maximum hostname length, and it's not huge. Also: isn't this function just saying "yes" or "no" to a candidate hostname? Can't it just say "no" if the hostname is super long?
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}
This looks like an "accident" by PR Agency: http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... From: Mar 27 Jan 15:28:45 CET 2015 Half an hour after Redhat lifted embargo from the ticket: https://bugzilla.redhat.com/show_activity.cgi?id=1183461 2015-01-27 10:03:14 EST Removed: EMBARGOED CVE-2015-0235 If this is true this lady gets an award for best security disclosure this year ;-)
Earlier quoted context omitted.
It seems it was made public by accident, so it is not totally surprising that information is sparse :(
Given that I recently received a Debian Security Advisory which specifically addressed this CVE, I don't think it was accidental at all.
This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6... Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 Debian bug: https://bugs.debian.org/776391 Great write-up from the discoverer (Qualys): http://www.openwall.com…
A note about Go. Go has its own DNS resolver, but unfortunately, if you compile natively, it's not enabled by default. It's only enabled if you cross-compile, or if you disable cgo, or if you rebuild the standard library with -tags netgo. /edit: a second note about Go; even without the native resolver, Go uses getaddrinfo, not gethostbyname*, and it's not vulnerable.
Earlier quoted context omitted.
We disagree on that, especially when they're widespread (and you don't get much more widespread than glibc) and "drop everything and patch"-level severity. Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.
I think the parent comment was sarcastic.
Adding a tagline, media friendly name or keywords is unprofessional. Simply, severity is then ranked by how popular the press or security bloggers can market the word, not by the respective severity of the CVE. Its a popularity contest, nothing more.
As someone who deals with every damn sensationalist story at a financial company, having every fucking client phone up about every damn marketoid creation even if it doesn't affect our platform detracts from doing real work.
Let's play their trick:
Its the X Factor of security.
All those home routers. All those home routers running Linux. All those home routers that are difficult to upgrade. All those home routers that will soon be part of some botnet or other?