Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


No worries | 24 comments | Create New Account
Click here to return to the 'No worries' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
No worries
Authored by: Moo0 on Jul 08, '02 02:50:29PM

This is more or less the same as what is happening with the latest winamp bug, where the auto-update function can be overflowed. One could then execute malicious code.

As long as you can trust your connection, this isn't much of an issue. DNS poisoning and spoofing is not something easy to do (though altering someone's DNS entry could be easy when you have either physical or remote access).

But, if you suspect your DNS server isn't reliable, then much more can go wrong. Who says your email isn't "screened", or your ssh sessions? If the traffic is routed properly and a different IP is given for an address, a lot more can happen.
This would work as follows: you connect to pop.server.com, which the DNS server gives IP 10.0.0.67 for but should be 213.45.38.212. You then connect (unknowingly) to the 10.* server which simply connects to the 213.* server and passes on any information; but can alter, monitor and spoof any data in between.

Hey, nobody said the internet was secure...



[ Reply to This | # ]
No worries
Authored by: Mikey-San on Jul 09, '02 02:38:41AM

Um.

No.

If I start an SSH session with a remote host (let's call it "Leet Remote Box"), I don't give a crap what's in between me and Leet Remote Box. Not the guys running the DNS boxes, not my provider, not even Miss Cleo.

It's encrypted via whatever encryption algorithm you've defined, and can't be read in transit as plain text--Secure SHell sessions look like garbage between hosts. If it didn't work like that, you may as well be using freakin' telnet. Here's where I shudder.

Nothing is truly secure (this Software Update thing isn't really new, since Windows Update and Debian's package update system, to name a few, also use straight http lookup requests in their update process), but SSH is certainly a Good Thing(tm).

My dual, shiny copper discs.


-/-



[ Reply to This | # ]
No worries - not entirely so
Authored by: Moo0 on Jul 09, '02 03:57:35AM

Yes, SSH traffic is supposed to be secure. But, you CAN intervene between a host and client; as long as the client thinks it's connecting to the host; and the host to the client.
It's unlikely for this to be undetected if the client has connected to the host before (an alert will be shown by ssh, stating the fingerprint has changed) and/or knows it's fingerprint which the client *should* always check. The user is usually noted on *NIX systems when conencting, from which IP it connected last time. This should alert the client.

Maybe i'm not clear enough, but here's how things should happen:
-client connects to server 1
-server 1 connects with server 2
-server 1 decrypt data between s1 and s2, and s1 encrypts data again for client

See http://www.kb.cert.org/vuls/id/786900 as well. If the user connects for the first time, or simply doesn't read the warning properly when the fingerprints differ from a previous connection - you have a hacked session.



[ Reply to This | # ]
How Apple could fix it (and open it)
Authored by: Anonymous on Jul 09, '02 04:35:30AM

Hi!
This exploit (same as the one possible on ssh, but there you will be warned) is called "man-in-the-middle-attack".
But it would be simple for apple to provide a public_key/signature with future "original installations", so all future data from Apple could be verified (they can also use gpg-signing or so, the point is, every mac needs to have a way to "proof" the software you download is indeed from Apple and no-one has hampered with it.
The benefit of this is, a corporate administrator can add (and add the public-key) for local update-servers.

However, for Apple, there is a bootstrap problem, to bring the public-key to every mac, you need to receive the correct one once - but it is not feasible for anyone to prevent the transfer of the correct public key on the long run. (Checkout the GPG or OpenSSH-Hompage on how to validate transfer public keys)

I hope this is helpful to clarify the situation,
iSee



[ Reply to This | # ]
How Apple could fix it (and open it)
Authored by: escowles on Jul 09, '02 08:51:10AM
There is a golden opportunity for Apple to distribute a public key for validating future Software Update releases: Jaguar. Assuming it's like 10.1 where they are going to distribute CDs, they could include it in the Jaguar CD and install it by default.

For that matter, since openssl is already installed by default, they could also switch Software Update to use SSL-encrypted communication, which would allow them to use the public key to validate the update server, in addition to the packages once they're downloaded.

They could also have a public key and a new version of Software Update for download at their website (https, of course, so it can be verified to be Apple).

-Esme

[ Reply to This | # ]