IRIX doesn't use GNU libc as its central C lib, so it wasn't affected by GHOST. Furthermore, GHOST itself was largely a non-event and absolutely no where near the scale of Heartbleed or Shellshock. Section 3 of that oss-security link highlights the threat level pretty well:
Code:
Select all
--[ 3 - Mitigating factors ]--------------------------------------------------
The impact of this bug is reduced significantly by the following
reasons:
- A patch already exists (since May 21, 2013), and has been applied and
tested since glibc-2.18, released on August 12, 2013:
[BZ #15014]
* nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME))
[HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was
successful.
* nss/digits_dots.c (__nss_hostname_digits_dots): Remove
redundant variable declarations and reallocation of buffer when
parsing as IPv6 address. Always set NSS status when called from
reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when
buffer too small. Correct computation of needed size.
* nss/Makefile (tests): Add test-digits-dots.
* nss/test-digits-dots.c: New test.
- The gethostbyname*() functions are obsolete; with the advent of IPv6,
recent applications use getaddrinfo() instead.
- Many programs, especially SUID binaries reachable locally, use
gethostbyname() if, and only if, a preliminary call to inet_aton()
fails. However, a subsequent call must also succeed (the "inet-aton"
requirement) in order to reach the overflow: this is impossible, and
such programs are therefore safe.
- Most of the other programs, especially servers reachable remotely, use
gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also
known as full-circle reverse DNS) checks. These programs are generally
safe, because the hostname passed to gethostbyname() has normally been
pre-validated by DNS software:
. "a string of labels each containing up to 63 8-bit octets, separated
by dots, and with a maximum total of 255 octets." This makes it
impossible to satisfy the "1-KB" requirement.
. Actually, glibc's DNS resolver can produce hostnames of up to
(almost) 1025 characters (in case of bit-string labels, and special
or non-printable characters). But this introduces backslashes ('\\')
and makes it impossible to satisfy the "digits-and-dots"
requirement.
The only reason GHOST got into the news was because one of these new cyber-intelligence firms sat on the vulnerability for several months while they worked on PR and marketing material prior to announcing it. Somehow, a link to the PR image got leaked out, and someone checked the creation date on it and noticed it was ~3 months old (Oct 2014, since this happened in Jan 2015), and blogged about it.
Ditto for the recent Qemu VENOM attack. Largely a complete non-event, since that only affected Qemu and Virtualbox users via antiquated floppy disk driver code (hah!), and it had a very narrow set of requirements in order to be exploitabe.
----------
If you really want to harden yourself from attack, there are a few easy, simple steps beyond the usual patching and firewall stuff, especially for Windows users, that can be followed:
Adobe:
- Disable Javascript in Adobe Reader/Acrobat.
- Disable Execution of embedded PDF Attachments in Adobe Reader/Acrobat.
- Install a browser add-on that prohibits automatic execution/loading of Adobe Flash/Shockwave.
Specific to Microsoft Office:
- Disallow automatic execution of macros, especially untrusted. If you wrote it yourself, MS has steps on creating a self-signed certificate that you can use to allow your own code to still run w/o prompting:
https://support.office.com/en-nz/articl ... 1c35079891
Java:
- If you have no choice but to use Java, then keep it up-to-date. If, for whatever reason, you're wedded to a specific, vulnerable version and you can't run multiple versions concurrently, then prevent your web browser from loading up Java content at all.
Those are the three, most commonly-used attack vectors in pretty much all cyber attacks these days. The fourth major vector is a "watering hole" attack, in which a legit website is compromised with things like hidden <IFRAME> tags that exploit a known or unknown browser vulnerability to load malicious code (and typically, this is actually done via Flash/Java, but there have been a handful affecting IE directly). A "spearphish" email is sent to a fairly-specific list of targeted individuals, usually on corporate systems, in an attempt to get them to visit the watering hole site and execute the exploit. These are a lot less common, and I'm fairly certain most people here are smart enough to not fall for your average spearphish e-mail.
If you already do all of these things, but know someone that doesn't, clue them in. Use a 2x4 if needed. A little pain can go a
very
long
way.
(2x)
We do NOT do "online banking." In fact, i refuse to have a fucking bank account. Those people are documented thieves, crooks and liars. And we don't do
