Apple Fails to Patch Critical Exploited DNS Flaw

On 30-Jul-2008, at 03:55, Randy Bias wrote:
> On Jul 29, 2008, at 6:42 PM, Ron Risley wrote:
>> On 29Jul2008, at 16:55, Randy Bias wrote:
>>> DNS cache poisoning is older than Jesus. Why do you think this is
>>> special?
>>
> [snip]
>>
>> Even so, I think there's a certain amount of hyperbole going on
>> here. Proper use of TLS/SSL (by users, not DNS servers) should fully
>> protect against damage from any DNS attack. After all, unless you're
>> running your own DNS servers, you might as well assume your DNS
>> servers are *always* compromised (unless you really trust the likes
>> of Comcast and AT&T).
>
> Right. This makes sense to me. That's why I'm confused about the
> headline, which feels fairly melodramatic. I guess it's good fun to
> bash Apple these days on security.

I checked the information, updated my own DNS servers to the
appropriate versions of bind, and then checked the version in OS X.
The versions in OS X where the versions of bind that did not have the
problem, so I ignored the issue as one more piece of FUD.

I don't know what the story really is now, the version of bind in my
leopard install is, according to bind, patched to avoid this issue.

It's a lot like that ARD thing last month. I tested ARD on my system
and got an error instead of the supposed hack, so I ignored the rest
of the posts on that issue as well.

On 30-Jul-2008, at 03:55, Danny Grizzle wrote:
> I want to continue to run my own DNS servers because it affords a lot
> of control and ad hoc ability to get things done. But Men & Mice have
> depreciated Macintosh support, and it is not clear what current best
> practices are. At least not for someone who does not do DNS
> configuration every day and is not totally immersed as a dedicated
> system administrator.


bind has a little learning curve and is unforgiving of the slightest
typo or mistake, but really once you get it setup the first time, it's
pretty much a 'leave it and forget it' application. Sure, you update
it as needed, but that is painless and seamless for the most part (the
move to bind9 was ... touchy).

This isn't "good fun to bash Apple on security" this is just outright
unacceptable performance on Apple's part regarding the safety and
security of what is perhaps the most critical portion of the
Internet's infrastructure.


>Anything that gets CERT to withhold a bulletin until the big day
>when essentially everyone except Apple
>releases patches simultaneously with the CERT bulletin is an attention
>grabber, not just the decade old cache poisoning idea.

Agreed. Also, a version check is NOT a promise of safety. On the day
of the announcement a script was released to check vulnerability, and
we ran it against our entire netblock and not only were we shocked by
the sheer number of machines running as DNS servers (several
hundred) but equally disappointed that all but 3 of them were
vulnerable.

That script has now been disabled since the release of exploits. To
my knowledge there is no longer a tool that can scan entire networks,
at least not any "white hat" tool. There are several sites that allow
you to check one server at a time and if you only have one or two I
strongly suggest you check them. I can tell you this, if they are
Macs, and you've only used Software Update to patch, they ARE
vulnerable.

In the three weeks since the announcement we have patched, helped our
clients patch, or flogged our clients to patch their servers. Right
now the number of servers that remain vulnerable is only numbered in
the "couple of dozen" but they all share a single commonality: They
are Apple computers running some version of MacOS X.

THAT is an embarrassment.

We are a little more than a week away from full disclosure of this
flaw. There are already several "one click" exploits out in the wild.
Apple has yet to release a patch, nor have they given any indication
that one is forthcoming. Meanwhile every other vendor has shipped a
patch, most within 24 hours of the announcement THREE WEEKS AGO.

DNS on OSX is ISC's BIND. BIND has been fixed since early May. Apple
was notified of the vulnerability of their systems on May 5th by
Vixie and Kaminsky. There is a patch, created by the open source
community available for MacOS X. However, like most OSS patches, if
you run it you risk breaking something when Apple (finally, if ever)
gets their patch shipped. Most of our clients running DNS on MacOS X
are just waiting for the official patch from Apple. Meanwhile their
servers are vulnerable. Apple is the LAST major vendor remaining
without a patch available for a widely known issue. If they don't get
this patch shipped within the next few days it will probably be the
death knell for anyone running public-facing Internet services on an
Apple-branded server.

I'll repeat: This isn't "good fun to bash Apple on security" this is
just outright unacceptable performance on Apple's part regarding the
safety and security of what is perhaps the most critical portion of
the Internet's infrastructure.

Honestly, I'm OK if Apple wants to stop selling servers and just
become a consumer-electronics company. Just tell us so we can toss
all these boxes out the window and buy from somebody who takes this
stuff, and their customers seriously.


--chuck

There are actually 2 big differences between this attack and
traditional cache poisoning.

Before, you were limited in the number of attacks you could execute by
the TTL. With this attack, there's no limit. Thus it takes seconds or
minutes to poison a cache.

Before, you could not overwrite an existing entry, just insert a new
one. Now you can not only overwrite a specific site, but all
of .com, .net, or whatever.

This is very definitely the most serious DNS flaw we've seen in a long
time; possible ever.

--On July 30, 2008 2:55:37 AM -0700 Danny Grizzle <dannymogulhost.com>
wrote:

> I want to continue to run my own DNS servers because it affords a lot
> of control and ad hoc ability to get things done. But Men & Mice have
> depreciated Macintosh support, and it is not clear what current best
> practices are. At least not for someone who does not do DNS
> configuration every day and is not totally immersed as a dedicated
> system administrator.

Take a look at djbdns. It already had sufficiently randomized ports prior
to this latest security issue. I switched my unix boxes to djbdns years ago
after the xth security attack against BIND. I've not installed it on a mac
but there are instructions out there:

<http://matt.simerson.net/computing/dns/djbdns-macosx.shtml>

I have no idea what side affects installing this might have. Glenn
suggested installing older, but patched, versions of BIND for a reason. I'd
treat using djbdns the same as a full upgrade of BIND, not just a simple
patch upgrade like Glenn's instructions.

--On July 30, 2008 2:55:36 AM -0700 Ron Risley <ronrisley.net> wrote:

> Even so, I think there's a certain amount of hyperbole going on here.
> Proper use of TLS/SSL (by users, not DNS servers) should fully protect
> against damage from any DNS attack.

Why? Proper use of SSL can protect you from phishing attacks, but not
malware installations. Say your DNS Cache gets poisoned against
www.google.com. You go there and your machine is taken over.

I'll point out web exploits agains the Mac have been done in just this
fashion. Get you to go to a compromised web site and exploit a bug in your
browser, use the script bug in Apple Remote Desktop to elevate to an
administrative user and the machine is theirs.

<http://www.securityfocus.com/news/11461>
<http://db.tidbits.com/article/9665>

With the DNS cache poisoned they don't need to trick you to a fake website,
no phishing tricks, as soon as you type in, or use one of your favorites,
you are taken to a compromised site. Amazon.com, google.com, apple.com, no
SSL for any of those sites (until you login or purchase something, but that
may not be what is being aimed for.)

Heck, gmail just now added the full time SSL option.
<http://db.tidbits.com/article/9710>

Yes, your mac security applies to a lot of this still (and Macs are still a
small target), but it applies to your Windows machines too. No phishing, no
bogus URLs, now your known addresses could be malware sites.

> After all, unless you're running
> your own DNS servers, you might as well assume your DNS servers are
> *always* compromised (unless you really trust the likes of Comcast and
> AT&T).

If you assume this then you should stop using names altogether and only use
IP only addresses. If you assume your DNS caches are compromised then you
can no longer send e-mail (it won't be delivered, or worse delivered to the
wrong server), same with all other network applications. MobileMe syncs are
all compromised better shut that off. Back to My Mac really won't work, VPN
connections won't work, etc....

Just look at the problems wildcard redirects cause for these types of
services.
<http://blog.washingtonpost.com/securityfix/2008/04/when_monetizing_isp_traffic_go.html>
<http://www.icann.org/en/announcements/advisory-19sep03.htm>

On 7/31/08 5:02 PM, "Ian Eiloart" <ianesussex.ac.uk> wrote:

> Now, it's not hard for a half-competent Unix sysadmin to update their BIND9
> named, so that would explain Apple's failure to rush to update.

No, it doesn't even come close. "It's easy, so we'll let our customers do
the work, and we can be the only OS vendor not issuing a patch"?

There is no, none, not even some imaginary excuse for Apple's behavior with
regard to this vulnerability.

--
John C. Welch

On 7/31/08 5:35 PM, "chuck goolsbee" <chucklistforest.net> wrote:

> That script has now been disabled since the release of exploits. To
> my knowledge there is no longer a tool that can scan entire networks,
> at least not any "white hat" tool. There are several sites that allow
> you to check one server at a time and if you only have one or two I
> strongly suggest you check them. I can tell you this, if they are
> Macs, and you've only used Software Update to patch, they ARE
> vulnerable.

Nessus will scan netblocks for all kinds of vulnerabilities. I use it
regularly.

> DNS on OSX is ISC's BIND. BIND has been fixed since early May. Apple
> was notified of the vulnerability of their systems on May 5th by
> Vixie and Kaminsky. There is a patch, created by the open source
> community available for MacOS X. However, like most OSS patches, if
> you run it you risk breaking something when Apple (finally, if ever)
> gets their patch shipped. Most of our clients running DNS on MacOS X
> are just waiting for the official patch from Apple. Meanwhile their
> servers are vulnerable. Apple is the LAST major vendor remaining
> without a patch available for a widely known issue. If they don't get
> this patch shipped within the next few days it will probably be the
> death knell for anyone running public-facing Internet services on an
> Apple-branded server.

I've directly told my Apple reps that if this is not patched by the end of
the week, along with an accompianing apology and explanation of how
processes will be changed to avoid this, that I'm going to start making sure
I never have an Apple OS directly facing the internet again. The delay here
is a symptom of a broken process. If the process is not fixed, it will
happen again, and I am no longer willing to accept unfounded Apple promises
in the security area.

> I'll repeat: This isn't "good fun to bash Apple on security" this is
> just outright unacceptable performance on Apple's part regarding the
> safety and security of what is perhaps the most critical portion of
> the Internet's infrastructure.

Chuck is being kind. It makes any Mac OS X box running Apple's shipped
version of BIND an actual *danger* to Internet users.

> Honestly, I'm OK if Apple wants to stop selling servers and just
> become a consumer-electronics company. Just tell us so we can toss
> all these boxes out the window and buy from somebody who takes this
> stuff, and their customers seriously.

Yep.

--
John C. Welch

On 31-Jul-2008, at 15:35, chuck goolsbee wrote:
> There are several sites that allow
> you to check one server at a time and if you only have one or two I
> strongly suggest you check them. I can tell you this, if they are
> Macs, and you've only used Software Update to patch, they ARE
> vulnerable.


Really? What sites are those? I mean, that might have been useful.

Here's the situation as I see it. If you are running bind, then you
should be capable of updating it. If you are not capable of updating
it, you should not be running it. The vast majority of Macs are not
running bind. It's a lot of sound and fury---and a lot of FUD since
for the vast majority of users, this is a meaningless issue. Upgrading
bind9 in place is actually trivial and takes only a couple of lines
that can easily be copy/pasted into a terminal window. And no, it
won't break when Apple updates, as the new binary will simply replace
the old.

# Mac OS x 10.5.4 Copy/Paste into terminal
curl -O http://ftp.isc.org/isc/bind9/9.4.2-P1/bind-9.4.2-P1.tar.gz
tar xzf bind-9.4.2-P1.tar.gz
cd bind-9.4.2-P1
./configure
sudo make install

# Mac OS X Server
curl -O http://ftp.isc.org/isc/bind9/9.4.2-P1/bind-9.3.5-P1.tar.gz
tar xzf bind-9.3.5-P1.tar.gz
cd bind-9.3.5-P1
./configure
sudo make install

once it's installed,

sudo rndc relaod

Voila! (and if you are running bind and you don't have the developer
tools and gcc installed... well, then you really have no business
running bind, do you?)

The config files don't need to change, none of your settings will be
overwritten, and everything will just work once you restart bind.

> Apple is the LAST major vendor remaining without a patch available
> for a widely known issue.

Really? I just checked. Here is the list from CERT of the 'unknowns'
and 'vulnerable'. These include Cisco, 3com, IBM, FreeBSD, Microsoft,
Fedora, D-Link, Belkin, and many others. perhaps CERT is not updating
their info?

<http://www.kb.cert.org/vuls/id/800113>

3com, Inc. Unknown 10-Jul-2008
Alcatel-Lucent Unknown 23-Jul-2008
Apple Computer, Inc. Unknown 5-May-2008
Avaya, Inc. Vulnerable 16-Jul-2008
Avici Systems, Inc. Unknown 21-Apr-2008
Belkin, Inc. Unknown 13-Jul-2008
Blue Coat Systems Vulnerable 22-Jul-2008
BlueCat Networks, Inc. Vulnerable 22-Jul-2008
Centre for the Protection of National Infrastructure Unknown 30-Jul-2008
Cisco Systems, Inc. Vulnerable 10-Jul-2008
Conectiva Inc. Unknown 5-May-2008
Cray Inc. Unknown 5-May-2008
D-Link Systems, Inc. Unknown 2-May-2008
Data Connection, Ltd. Unknown 21-Apr-2008
Debian GNU/Linux Vulnerable 9-Jul-2008
dnsmasq Vulnerable 11-Jul-2008
DragonFly BSD Project Unknown 3-Jul-2008
EMC Corporation Unknown 21-Apr-2008
Engarde Secure Linux Unknown 5-May-2008
Ericsson Unknown 21-Apr-2008
Extreme Networks Unknown 21-Apr-2008
F5 Networks, Inc. Vulnerable 14-Jul-2008
Fedora Project Unknown 5-May-2008
FreeBSD, Inc. Vulnerable 14-Jul-2008
Fujitsu Vulnerable 18-Jul-2008
Gentoo Linux Vulnerable 12-Jul-2008
Gnu ADNS Unknown 5-May-2008
GNU glibc Unknown 5-May-2008
Hewlett-Packard Company Vulnerable 16-Jul-2008
Honeywell Unknown 21-Apr-2008
IBM Corporation Vulnerable 12-Jul-2008
IBM Corporation (zseries) Unknown 5-May-2008
IBM eServer Unknown 21-Apr-2008
Infoblox Vulnerable 21-Jul-2008
Ingrian Networks, Inc. Unknown 5-May-2008
Intel Corporation Unknown 21-Apr-2008
Internet Systems Consortium Vulnerable 14-Jul-2008
Juniper Networks, Inc. Vulnerable 10-Jul-2008
Linux Kernel Archives Unknown 3-Jun-2008
Lucent Technologies Unknown 21-Apr-2008
Luminous Networks Unknown 21-Apr-2008
Mandriva, Inc. Vulnerable 22-Jul-2008
Men & Mice Unknown 5-May-2008
Metasolv Software, Inc. Unknown 5-May-2008
Microsoft Corporation Vulnerable 8-Jul-2008
MontaVista Software, Inc. Unknown 5-May-2008
Motorola, Inc. Unknown 21-Apr-2008
Multinet (owned Process Software Corporation) Unknown 21-Apr-2008
Multitech, Inc. Unknown 21-Apr-2008
NetApp Unknown 3-Jul-2008
NetBSD Unknown 5-May-2008
Netgear, Inc. Unknown 21-Apr-2008
Network Appliance, Inc. Unknown 21-Apr-2008
Nixu Vulnerable 9-Jul-2008
Nokia Unknown 21-Apr-2008
Nominum Vulnerable 10-Jul-2008
Nortel Networks, Inc. Unknown 21-Apr-2008
Novell, Inc. Vulnerable 14-Jul-2008
OpenBSD Vulnerable 24-Jul-2008
Openwall GNU/*/Linux Vulnerable 17-Jul-2008
Posadis project Unknown 14-Jul-2008
QNX, Software Systems, Inc. Unknown 5-May-2008
Red Hat, Inc. Vulnerable 10-Jul-2008
Redback Networks, Inc. Unknown 21-Apr-2008
Secure Computing Network Security Division Vulnerable 17-Jul-2008
Shadowsupport Unknown 5-May-2008
Siemens Unknown 8-Jul-2008
Silicon Graphics, Inc. Unknown 5-May-2008
Slackware Linux Inc. Vulnerable 12-Jul-2008
Sony Corporation Unknown 21-Apr-2008
Sun Microsystems, Inc. Vulnerable 31-Jul-2008
SUSE Linux Vulnerable 11-Jul-2008
The SCO Group Unknown 5-May-2008
Trustix Secure Linux Unknown 5-May-2008
Turbolinux Unknown 5-May-2008
Ubuntu Vulnerable 10-Jul-2008
Wind River Systems, Inc. Vulnerable 9-Jul-2008
Yamaha Corporation Vulnerable 29-Jul-2008
ZyXEL Unknown 21-Apr-2008

On 7/31/08 6:58 PM, "LewisGmail" <gkremegmail.com> wrote:

> Here's the situation as I see it. If you are running bind, then you
> should be capable of updating it. If you are not capable of updating
> it, you should not be running it. The vast majority of Macs are not
> running bind. It's a lot of sound and fury---and a lot of FUD since
> for the vast majority of users, this is a meaningless issue. Upgrading
> bind9 in place is actually trivial and takes only a couple of lines
> that can easily be copy/pasted into a terminal window. And no, it
> won't break when Apple updates, as the new binary will simply replace
> the old.

If you are running OS X server in a k-12 situation, (You know, where Apple
sells based on "point and click), then you're running BIND. Assuming that
situation even knows they're running bind.

Apple has made a lot of press and even more money with the "We take care of
the hard stuff for you", and they have completely and utterly dropped the
ball as the OS vendor in this case.

It is not FUD to point this out. It is not FUD to point out that Apple has
behaved in a completely wrong manner here.

It is not FUD to expect that within THREE MONTHS, Apple can release a simple
patch that helps keep their stuff from NOT BEING DANGEROUS.

It is not FUD to point out that if I'm going to maintain my own BIND et al,
since Apple cannot be trusted to issue security patches in a timely manner,
then why exactly do I need to pay for Apple hardware and Apple OS's when I
can get equal quality hardware and OS's from HP, and for *half* of Apple's
price?

There is no excuse for Apple's behavior here. None. TO try to justify
Apple's behavior as anything else is MacMacism writ large.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

Here is the big problem with everyone that is downplaying Apple's
responsibility for providing a fix to the BIND problem. They sold a
solution to customers that promised to provide ease of setup,
maintenance and administration. They failed spectacularly with this
security issue. Many people running Mac OS X Server really don't have
the ability to update bind on their own. Saying it's not a critical
update because anyone who is using it should be able to update it
without Apple's help is ignoring the fact that they shouldn't even
have to. Apple provided a hardware and software solution and it is
their responsibility to fix critical security vulnerabilities in a
timely manor. This clearly didn't happen.

The second problem with "update it yourself" is that Apple updates
have been known to be brittle when they encounter an environment that
doesn't happen to be what they expect. Now would it happen in this
case? I have no idea, probably not. But on the other hand could anyone
guarantee that nothing would happen? If you said yes well I have some
beach front property that I want to sell you sight unseen.

Now onto two areas of people that people only addressing Mac clients
don't seem to get, hosting providers and network/server admins.
Hosting providers that let clients host their own servers have their
hands pretty much tied here. Now I'm not just talking about local mom
and pop providers, I'm talking about every provider that does this.
Those who think this is just a client issue would be truly surprised
at the names involved. So what are they to do? Cut off network access
to protect their clients users until the problem is fixed? Read the
two paragraphs above about why that could be problematic. Then cut to
the tech support lines where people are screaming about lost revenue,
service uptime, contract guarantees, etc. Please note that these are
clients that are not complaining to Apple so the world doesn't hear
their pain, but to their service provider. Many of them running Mac OS
X as a client. So increase the number of Mac clients affect by several
orders of magnitude.

Then we get to network/server admins that have deployed Mac OS X
Server. I ask you to please read again the second paragraph, So we
have a situation where it's possible for a quick fix but a potential
problem in the future. Granted it may or may not happen, but from
experience some very small things have completely borked up upgrades.
So savior one day and pariah the next. Rock and a hard place much?
Let's get back to my first paragraph, why should this be a worry to
any admin, knowledgeable or otherwise? Oh and trust me, most admins
that deal with Macs and Windows clients and servers know what the hell
they are doing. So they could update BIND then deal with the
ramifications. The point is they shouldn't bloody have to. Since
multiple people have pointed out what a simple fix it is, why couldn't
Apple have rolled out an update two or three weeks ago? Oh and
remember each of these admins also have users running Mac OS X as a
client so are also vulnerable. Raise the order of magnitude again.
It's not just a small amount of users, it's quite large amount of
users but the only voice you see are the admins.

This is why it's important. This is also why anyone who as ever
installed/sold Mac OS X Server is extremely pissed off. And why I
don't think most if any of them will ever do it again. It seems like
Apple is again getting out of the server room, this is fine. They
don't have to do corporate IT. But it would have been nice to let
people know before they abandoned then.

By the way the list of vulnerable systems that lewisgmail.com posted
was out of date. It's hard to determine which day he actually sent the
email due to the moderation of this list, but I checked after
receiving the message (on July 31 2008) and the list on the CERT site
is very different.

--
Michael
----------------------------------------------------------------
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

cuz I find it funny

At 3:58 PM -0700 7/31/08, LewisGmail wrote:
>On 31-Jul-2008, at 15:35, chuck goolsbee wrote:
>>There are several sites that allow
>>you to check one server at a time and if you only have one or two I
>>strongly suggest you check them. I can tell you this, if they are
>>Macs, and you've only used Software Update to patch, they ARE
>>vulnerable.
>
>
>Really? What sites are those? I mean, that might have been useful.

Dan Kaminsky's site for one: <http://www.doxpara.com/>. Look for the
prominent button that says "Check my DNS".
Or try <https://www.dns-oarc.net/oarc/services/dnsentropy>.

The story is important enough that it is pinned to the top of The Register.
Slashdot has been running it for nearly a month.


>Here's the situation as I see it. If you are running bind, then you
>should be capable of updating it. If you are not capable of updating
>it, you should not be running it.

"If you are driving a car, you should be capable of dismantling and
rebuilding the engine." That is an equally unrealistic and illogical
statement.

Running servers is no longer the exclusive domain of
super-specialists. No matter how much you may decry the fact that
normal people now run servers for business or fun or just to avoid
being subject to the vagaries of their ISP*, the fact is that normal
people do run their own servers - which frequently means running DNS,
IIS, Apache, MySQL and various other applications that they do not
completely understand. To make a blanket statement as above is
frankly unrealistic.


> The vast majority of Macs are not
>running bind. It's a lot of sound and fury---and a lot of FUD since
>for the vast majority of users, this is a meaningless issue.

Perhaps in your vigor to proclaim that this is not a problem, you
have overlooked the fundamental issue that this constitutes an
ultimate man in the middle attack. My Mac doesn't have to be running
DNS for me to be deeply affected. I can simply want to buy a new book
from Amazon, or a Take Control book. I type in the name of the
website - but if my ISP has been affected by this DNS attack then my
request is redirected to a fraudulent website that is masquerading as
Amazon or eSellerate. None of a) my machine, b) Amazon's servers, c)
eSellerate's servers have been touched or attacked. In fact I'm not
even running DNS on my machine. But if my ISP was slow to respond in
patching, then my query to their DNS server could have been hijacked
and sent off to a fraudulent site that is even running SSL so it
looks good to me.

All of the named parties are innocent bystanders, but have been
victimized by a classic and especially powerful MITM.


*Is your ISP's server patched?

On Thu, Jul 31, 2008 at 6:58 PM, LewisGmail <gkremegmail.com> wrote:
> Here's the situation as I see it. If you are running bind, then you
> should be capable of updating it. If you are not capable of updating
> it, you should not be running it.

Ridiculous; MOSXS provides perfectly useful front end, such that you
have no need to know it's even BIND.

> Upgrading
> bind9 in place is actually trivial and takes only a couple of lines
> that can easily be copy/pasted into a terminal window.

If you're comfortable with that.

And if not (arguably, Apple's target market), and you get off in the
weeds, then what?

> And no, it
> won't break when Apple updates, as the new binary will simply replace
> the old.

Probably.

And if not, and the next time you run Software Update, DNS (or
something worse) fails, then what?

Responsibility for this is squarely in Apple's court, not the user's.

- Marc

[Thankfully, Apple has stepped up. -Andrew ]

On 31Jul2008, at 14:35, Kevin van Haaren wrote:

> Proper use of SSL can protect you from phishing attacks, but not
> malware installations. Say your DNS Cache gets poisoned against
> www.google.com. You go there and your machine is taken over.

If your machine is vulnerable to drive-by exploits and malware
installation, it's vulnerable whether or not your DNS is compromised.
Adding DNS cache poisoning to the picture at best makes the attack
incrementally easier, but you'll be pwned sooner rather than later
anyway unless you never visit sites that you have not personally
verified to be currently safe.

> I'll point out web exploits agains the Mac have been done in just this
> fashion. Get you to go to a compromised web site and exploit a bug
> in your
> browser, use the script bug in Apple Remote Desktop to elevate to an
> administrative user and the machine is theirs.
>
> <http://www.securityfocus.com/news/11461>
> <http://db.tidbits.com/article/9665>

These exploits had nothing to do with DNS cache poisoning.

> With the DNS cache poisoned they don't need to trick you to a fake
> website,
> no phishing tricks, as soon as you type in, or use one of your
> favorites,
> you are taken to a compromised site. Amazon.com, google.com,
> apple.com, no
> SSL for any of those sites (until you login or purchase something,
> but that
> may not be what is being aimed for.)

Uh, *all* those sites support SSL (with valid certificates):

https://www.google.com
https://www.amazon.com
https://www.apple.com

Google immediately redirects to an unencrypted link, but only *after*
your browser has verified their certificate.

> Heck, gmail just now added the full time SSL option.
> <http://db.tidbits.com/article/9710>

No, gmail has always had a full-time SSL option. All you had to do, as
the cited article points out, was start your session using SSL. The
only thing that has changed is that now you can *require* an SSL
connection.

>> After all, unless you're running
>> your own DNS servers, you might as well assume your DNS servers are
>> *always* compromised (unless you really trust the likes of Comcast
>> and
>> AT&T).
>
> If you assume this then you should stop using names altogether and
> only use
> IP only addresses.

And when it matters, I do use IP addresses (or signed certificates).
My VPNs, mail tunnels, shell logins, and VNC links are all configured
this way.

> If you assume your DNS caches are compromised then you
> can no longer send e-mail (it won't be delivered, or worse delivered
> to the
> wrong server),

It is always a good assumption that this might happen. I never, ever
send even a patient's name in an email unless they have agreed to
public exposure or I can establish an end-to-end TLS connection with
the destination client (rarely possible) or can use application-level
encryption. If you're counting on email being private, secure, or
reliable, then you're making a big mistake (even if you *could* trust
the entire DNS infrastructure).

> same with all other network applications. MobileMe syncs are
> all compromised better shut that off.

You bet. Again, if you're really relying on MobileMe to be private,
secure, and reliable then you are eventually going to run into problems.

> Just look at the problems wildcard redirects cause for these types of
> services.
> <http://blog.washingtonpost.com/securityfix/2008/04/when_monetizing_isp_traffic_go.html
> >
> <http://www.icann.org/en/announcements/advisory-19sep03.htm>

Hmmmm, and those bad things happened with uncompromised name servers
run by "trusted," "reliable" entities. (Much as I despise the policies
of Network Solutions, I doubt they're really any less trustworthy than
Verizon or Comcast.)
>

No, DNS cache poisoning attacks are significant, but they're not the
vulnerability of the decade by a long shot. No machine has ever been
directly pwned by a DNS cache poisoning attack, nor ever will be. DNS
was insecure, vulnerable, and unreliable before the Kaminsky exploit.
We all knew it, we all use DNS anyway, and we all take steps to insure
that we don't *rely* on DNS.

--Ron

On 1/08/2008 10:58 AM, "LewisGmail" <gkremegmail.com> spake thus:

> Centre for the Protection of National Infrastructure Unknown 30-Jul-2008

I find this one particularly ironic :) (although admittedly "unknown"
probably just means "they haven't said anything publically")

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://xri.net/=nigel.stanger

You can take down your article now.

http://www.macrumors.com/2008/07/31/security-update-2008-005-released/

-g

On Fri, Aug 1, 2008 at 3:07 AM, Ron Risley <ronrisley.net> wrote:
> We all knew it

And there is the Achilles heel in the argument; very few of users of
DNS knew it.

The same way very few users of email know it's insecure.

The same way very few drivers know how to jump-start their car.

Etc.

It's up to we geeks of the world to not only educate and assist, but
more importantly to fix the systems. Or redesign them as need be.

Don't castgate users for doing things they "should have known not to"
- castigate the profiteers who sold so many people on technologies
that were not designed for what they're now used.

--On August 1, 2008 12:07:26 AM -0700 Ron Risley <ronrisley.net> wrote:

> On 31Jul2008, at 14:35, Kevin van Haaren wrote:
>
>> Proper use of SSL can protect you from phishing attacks, but not
>> malware installations. Say your DNS Cache gets poisoned against
>> www.google.com. You go there and your machine is taken over.
>
> If your machine is vulnerable to drive-by exploits and malware
> installation, it's vulnerable whether or not your DNS is compromised.
> Adding DNS cache poisoning to the picture at best makes the attack
> incrementally easier, but you'll be pwned sooner rather than later
> anyway unless you never visit sites that you have not personally
> verified to be currently safe.

DNS Cache poisoning makes other attacks orders of magnitude easier, not
incrementally easier.

I've verified www.google.com to be safe. I don't click links in e-mail. I
open my browser click my shortcut to google (that has been safe a thousand
times in the past) and I'm no longer at a safe site, with a bit of simple
work to make the web page appear to be google and I wouldn't be able to
tell.

>> I'll point out web exploits agains the Mac have been done in just this
>> fashion. Get you to go to a compromised web site and exploit a bug
>> in your
>> browser, use the script bug in Apple Remote Desktop to elevate to an
>> administrative user and the machine is theirs.
>>
>> <http://www.securityfocus.com/news/11461>
>> <http://db.tidbits.com/article/9665>
>
> These exploits had nothing to do with DNS cache poisoning.

Yes it does. DNS cache poisoning makes these attacks orders of magnitudes
easier.


>> With the DNS cache poisoned they don't need to trick you to a fake
>> website,
>> no phishing tricks, as soon as you type in, or use one of your
>> favorites,
>> you are taken to a compromised site. Amazon.com, google.com,
>> apple.com, no
>> SSL for any of those sites (until you login or purchase something,
>> but that
>> may not be what is being aimed for.)
>
> Uh, *all* those sites support SSL (with valid certificates):
>
> https://www.google.com
> https://www.amazon.com
> https://www.apple.com

How often do you actually use those, how often does the general public use
them? How often do you get to those sites by clicking links on other
peoples sites instead of clicking them yourself? I've seen a lot of
embedded google search bars on web pages that redirect to google. None that
I can recall go to the SSL page. I've seen an awful lot of Amazon
affiliate links don't use SSL.

In fact check the source code on Amazon.com and Apple.com, you'll find a
whole host of links that direct you right back to non-SSL
http://www.amazon.com

Because the sites are loading stuff from non-SSL here's how you get around
SSL protection (or abuse it to your advantage):
You've compromised the router and web server for a company and have setup
EvilNetwork. You poison the cache for www.google.com. You configure the
router so that all port 443 traffic is routed (just like a router is
supposed to) to the real https://www.google.com/. Then when
http://www.google.com/ redirects the computer back to port 80 http: you
direct that traffic to your own site. Initial SSL page: pass, redirect:
compromised.

Fun with Apple SSL: Check the source, it loads images and scripts from
http://images.apple.com/. Configure the cache poisoning so www.apple.com
still goes to Apple, but images.apple.com come from your web site. Now you
get an SSL approved page from Apple, but javascript from EvilNetwork.
Brilliant!

> No, DNS cache poisoning attacks are significant, but they're not the
> vulnerability of the decade by a long shot. No machine has ever been
> directly pwned by a DNS cache poisoning attack, nor ever will be. DNS
> was insecure, vulnerable, and unreliable before the Kaminsky exploit.
> We all knew it, we all use DNS anyway, and we all take steps to insure
> that we don't *rely* on DNS.

I'm glad you know how every computer on a million bot botnet gets
compromised. Dismissing dns cache poison attacks because we've known about
them for years would be like the medical community in 1918 dismissing that
new flu variant going around because we've known about flu for thousands of
years.

And it's impossible to not rely on DNS. Sorry but that's the way the
internet works. Even attempting to use IPs instead of names isn't going to
work, you'll get redirected or scripts will load from a name and you can
never click a web site link. Even if you do only use IPs how do you get
those IPs? Do you look them up from the command line? Oh, sorry DNS is
compromised can't do that.

On 1-Aug-2008, at 00:58, John C. Welch wrote:
> It is not FUD to expect that within THREE MONTHS, Apple can release
> a simple
> patch that helps keep their stuff from NOT BEING DANGEROUS.


So you expect that Apple has to be first out of the gate with
patches? There were a LOT of vendors who still weren't patched just a
couple of weeks ago.

> It is not FUD to point out that if I'm going to maintain my own BIND
> et al,
> since Apple cannot be trusted to issue security patches in a timely
> manner,
> then why exactly do I need to pay for Apple hardware and Apple OS's
> when I
> can get equal quality hardware and OS's from HP, and for *half* of
> Apple's
> price?

Equal quality hardware and software for half the price? Is it 1990
again?

I don't think so.

On 1-Aug-2008, at 01:00, Michael Krzyzek wrote:
> Apple provided a hardware and software solution and it is
> their responsibility to fix critical security vulnerabilities in a
> timely manor. This clearly didn't happen.


Oh, this is just getting silly. How long a period are we talking
about here? It's not years. It's not even months. It's a couple of
weeks delay. At most. The first post on this was *FIVE DAYS* ago.
FIVE DAYS! And the patch came out YESTERDAY.

So, a *FOUR DAY* spread on this topic between when (most?) TidBITS
readers first became aware of it and when Apple released a patch. And
Apple's patch addressed a few different issues, so required some more
testing I'd imagine. Heck, just getting php 5.2.6 rolled in is a chore.

> By the way the list of vulnerable systems that lewisgmail.com posted
> was out of date. It's hard to determine which day he actually sent the
> email due to the moderation of this list, but I checked after
> receiving the message (on July 31 2008) and the list on the CERT site
> is very different.

That was the list as CERT had it when I posted at 31 July 2008
16:53:54 MDT. As far as I know, moderation does not change the Date
Header. at least my sent copy and my received copy have the same date
header.

The current page says Apple is vulnerable and the status was updated
today. It says Microsoft is vulnerable and the status was updated the
8th. It's not a very useful list, evidently.