Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Apple Businesses

Mac OS9 Flood Attack 185

Yoel Inbar writes "John Copeland, a professor at Georgia Tech, has discovered the possibility of using Macs running OS 9 as a distributed DOS tool. Basically, by sending a Mac running OS 9 a custom UDP packet, you can get it to reply with a 1500 byte ICMP packet(these packets are normally sent as part of MTU discovery). Send these UDP packets to a bunch of Macs, spoof the source addresses....voila, instant DOS. Apparently this is "in the wild"; he reports several scans designed to elicit these packets. "
This discussion has been archived. No new comments can be posted.

Mac OS9 Flood Attack

Comments Filter:
  • Now that is not completely true.

    The fact that you have to send as many packets as the recipient of the DoS attack is true, but from how I interpret the announcement, no matter how small the UDP packet is a 1500 byte ICMP packet will always be returned.

    This is a bit odd. Why 1500 bytes? It is the MTU for Ethernet, but I can't really see how that should affect the size of the ICMP error message. Maybe the fellows at Apple made an error in the internal coding of packet length, and the ICMP error-return code included the sent packet and then garbage up until the 1500 byte limit.

    However, it can never be as destructive as a smurf attack (unless you have a whole subnet filled with Macs running OS9 _and_ they answer with this ICMP on broadcast packets to the specific port). Also, if it is only one specific UDP port, it is pretty easy to block in firewalls.

  • One 44k packet gets amplified to one 1500k packet. From the site:

    Here I have three slaves (199.77.146.20, 199.77.146.103, 199.77.158.61) being stimulated to send 30 1500-byte packets per second to address 24.88.48.47 (my cable modem). The combined bit rate is 3 x 30/s x 1500 bytes x 8 b/B = 1,080,000 bits/s. I could have increased the rate several times, but not much more would have interfered with the network.

    -kris

  • Actually 9x is avoided. NT is, as you say, used "as little...as possible." I'm not one to vouch for the use of any Windows platform or Linux distribution, but I will say that I have never had a prejudice against MacOS, which seems like a secure enough OS from a network standpoint (notice that I did not include stable, however ;-).

    I, too, find it interesting that such attention is targeted specifically toward OS 9 when all the facts have yet to be laid out. And yes, it is correct that all OSes have the ability to react in the manner as in the original post.

    I will differ from you in that I believe OpenBSD is the most secure out-of-box solution. As for "easiest" to maintain, well... ;-)

    Oh, and these are my views, not the university's. =)

    Thanks,
    dtc

    (who is very pleased with his extremely secure stand-alone TI-30)
  • Well, I was about to put the URL of the patch to fix this in, but it seems that some people beat me to it (http://asu.info.apple.com/swupdates.nsf/artnum/n1 1559 in case those other posts are below your threashold).

    Anyway, I fail to understand why such an obscure bug has propted such heated responses. Bugs happen to everyone - Apple, Microsoft, and even Linux. Unfortunately, they are a fact of life. Programmers are only human after all. What puzzles me is that this story went up within hours of it first being written, while a story that I sent in several weeks ago that was Apple related (the HeaderDoc, Netsprockets announcement) was rejected within minutes only to be posted a while later.

    Not that I'm suggesting anyone has a double standard of course, I know it's hard to sift through hundreds of story submissions. Still...

  • This is not a new thought. Using many machines on many subnets to flood an IP in concert. This particular incarnation of this attack is just another straw in the haystack. Given knowlege if the functionality of a client's stack, you should be able to find a way to make it do similar things. Just spoof an IP and ping it....there's no genius to that. Using false return addresses has been a tool of the malevolent since people hung numbers on their caves. Actually, using one OS to do this is unwise because one patch or fix can foil all your plans. It is tactically more sound to use multiple OS's in such a scheme, so that if one OS fixes the problem, the others may still function properly.

    I'm just glad people still think these are ingenious means of attack. There are much more devilish ways to DoS.
  • we covered this story at MacWEEK pretty well, i thought.

    see for yourself [zdnet.com]
  • Apple's servers seem to be down(coincidence?), but the fix should be right here:

    http://asu.info.apple.com/swupdates.nsf/artnum/n 11559
  • by Rilke ( 12096 ) on Tuesday December 28, 1999 @10:50AM (#1438023)
    The difference here is that I can trigger a response much larger than the request. If I send an ICMP ping of 1000 bytes, the response is going to be 1000 bytes.

    But with this attack, I can trigger a response of 1024 bytes by sending only 24 bytes. The idea being that I can fill the victims pipeline without filling my own.

    But for the most part that's just bogus. The difference in size just isn't that great. A script kiddie will fill his own ppp bandwidth with the triggers long before whitehouse.gov gets overloaded with the payload. Also, much of the bottleneck is due to # of packets rather than # of bytes, and the # of packets is identical for attacker and victim.

    Apple should fix the hole, but in the grand scheme of things this isn't huge security news, especially given the paucity of Mac servers on the Net (where this could really do some damage).

  • I think there would have to be an AWFUL LOT of Mac slaves to actually swamp a DS-3 connection. In fact, I bet it isn't even possible.

    You mean a lot of MacOS 9.0 slaves. How old is 9.0 anyhow? Three months? There is already a low enough population of Macs on the live-connected Internet for this to be difficult to exploit, but they also have to be upgraded to a three-month old OS, too! "I don't think so, Tim."


  • Don't know if this is related, but here is a link to the Cert Advisory [cert.org] discussing how Mac OS9 can be used as a 37.5 times DoS amplifier.

    Hope this helps.

  • How big is the ethernet frame that carries the 29 byte packet? 1500 bytes. This is a 1:1 attack. You could probably do twice as much damage if you just ping flooded from the unix box on the large pipe you rooted.

    True, you get a bit of a multiplier in the response, but this still isn't an attack with a multiplier. Its not like the mac sends the same packet back out to the broadcast address which then starts all the other macs doing this. It would be more effective just to ping flood them from the rooted box on the big pipe. Think about it, if you have rooted a unix box on a fat pipe to coordinate the attack, why not just attack from there?
    --
    Mike Mangino Consultant, Analysts International
  • Funny, consensus so far is that there isn't even a problem.

    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])
  • How is this 'supposed' new DoS attack different from what we've already seen?

    Sounds simple in principle:
    Pretend to be your target (IP spoof)
    Ping a bunch of Macs
    Watch real target fall over as all the Macs respond to the ping

    How and why is this different? The 1500b packet? Is MacOS 9 unique in this?

    Pardon my ignorance, just really curious.
  • I'm not very familiar with IP spoofing, but isn't this possible with every system everywhere all the time?

    If I sent ping packets with spoofed IPs to three hundred machines running any OS, wouldn't they respond with packets to the target machine?

    -konstant
    Yes! We are all individuals! I'm not!

  • well, this might be some 'hoax', but *someone* at apple posted a patch even though they seem to be off...

    this is really standard stuff, there are at least as many misconfigured routers out there (on biggger pipes) than static IP OS9 machines... i doubt the existence of ANY Y2K plot using these machines...

    anyway, the patch is at:

    ftp://ftphqx.info.apple.com/Apple_Support_Area/A pple_Software_Updates/English-North_Americ an/Macintosh/Networking-Communications/Open_Transp ort/OT_Tuner_1.0.smi.hqx
  • Those macs are good for something.

    j/k

  • by technos ( 73414 )
    Now you can say to someone, 1930's gangster-style, that you're going to iWhack them.

    I can see this kind of distributed DOS being called the 'iWhack Attack'.
  • by Anonymous Coward
    Many systems, when they receive UDP packets on an unbound port, will reply to the source address with an ICMP Port Unreachable message. One of the RFCs recommends rate-limiting ICMP messages. Apparently, Apple (or their supplier) didn't implement this suggestion.
  • by kevin lyda ( 4803 ) on Tuesday December 28, 1999 @10:18AM (#1438039) Homepage
    apparently included in the ms investment, ms gave apple "some really good tcp/ip stack programmers."
  • 1. OS 9.0 didn't sell well.
    2. There aren't many mac users with cable modems because we are all poor from buying overpriced hardware.
    3. See #1 and #2

    no big deal.
  • Wow, I never thought of using an OS's built-in networking code against itself, but heck, this sounds neat-O!

    Really, this is a serious security issue. As an admin, I rue the day that OS9 is deployed if such a possibility remains "in the wild." Being stuck in the middle of AOL's subnet doesn't help, either, but at least eliminating this one source will save myself and countless others the hassle of hoping and praying that no script kiddie gets his hands on a tool to exploit this vulnerability.
  • According to this professor it's a iWhack conspiracy against the connected world as we now it in this millenium :-)

    (website excerpt)
    This page presents evidence of a conspiracy to shut down Internet Connections. Zero-hour is probably New Years Eve, EST.

  • by waldoj ( 8229 ) <waldo&jaquith,org> on Tuesday December 28, 1999 @10:22AM (#1438046) Homepage Journal
    I believe that this 3rd party patch [sustworks.com] may permit you to change your OT settings to prevent this.
  • Apple engineers and beta teams are on vacation until January 3. I don't know if this has already been addressed in the next patch to MacOS 9, but I guess they'll fix it now that it's known. Does this work in older versions of the MacOS?
  • Hmmm.. I'm running of the RC2 and 3 in a variety of roles. (I kept the early machines 'cuz I'm lazy and the bugs are pretty much worked around) While I'm not primary support for those machines, I haven't heard of this flaw. As we plan on 'early adopting' W2k, and I'm unlikely to get a straight answer from Microsoft, do you have any further detail?
  • Apple posted a patch to the Open Transport Stack on its web page at
    Open Transport Tuner 1.0 [apple.com]. You may also find more information on the Mac Attack FAQ [mediaone.net].
  • "Help! My iMac is on UDP crack!"
  • No one ever installs those things. If every ISP filtered packets originating in the ISP with source addresses outside the ISP, smurf attacks (And several others) would be eliminated, too. The reasons are the same -- sheer ignorance. Bummer.
  • by barbaBob ( 56615 ) on Tuesday December 28, 1999 @11:00AM (#1438054)
    I take it that you don't deploy Windows 95, 98 or NT either because of the vulnerabilities that those particular operating systems have, especially in networked environments?

    What strikes me as a bit weird is that whenever the MacOS operating system has such a vulnerability everybody is going ballistic, like if it proves a point they have been making all along. Might be my peculiar way of looking at things tho :)

    I've been working with all three operating systems for quite a few years now, and MacOS - at least up to 8.6 - remains the most secure out-of-the-box operating system out. A well tuned and maintained Mac server remains one of the most secure internet platforms out there. Is up and running in less than a minute, a snap to set up and maintain.

    Of course, it has purposes it's best suited for and situations you'd rather not use one. Same goes for Linux, or any other operating system out there. Which is why I use MacOS, Linux and IRIX, and as little NT as possible :)

    Cya
    bBob

    (who is very happily running a mixed MacOS/Linux setup)

  • yeah, except the ICMP_ECHO_REPLY is the same size as the ECHO_REQUEST you sent. Go read the good prof's write up. It points out that a 29 byte packet gets a 1500 byte reply. So your 33.6 modem could easily fill a T1. Try that with ICMP_ECHO.

    Its not as bas as smurf was, but don't write this off.
  • Aparently this attack is real, at least it is mentioned at cert.org under the distributed DOS attack section. However, all this conspiracy y2k talk on Prof. Copeland's site seems overdone. CERT terms this a 'traffic amplifier' in the sense that a small amount of bandwith can create approximately 37.5 times the bandwith spent. From CERT on Dec 28th: "For the "Mac Attack" Apple is developing a patch, as described in Appendix A. This advisory will be updated when the patch is available. "
  • Exactly what I was thinking. I'm sitting here in the middle of three Linux machines (one's an Alpha) and two Macs. Strange that I haven't seen this kind of outcry about the morons on the various @Home networks that leave their Wintel machines open for mail relaying, or the widespread use of Back Orifice on those same networks to base secondary attacks. We're not talking about a "vulnerability" here - we're talking about the fact that an attack can be "relayed" due to a flaw in the way that the Mac OS implements the Mentat Streams. I know where there's a Mac IIsi running AIMS that's had *zero* downtime for the past 27 months, with one exception - they shut down the power to that closet without telling anyone, and the UPS kept it going until the bitter end. As soon as the power came back on, it brought itself back up and kept right on going. Were anyone to examine the percentages, I think they'd find that Windows machines (of *all* flavors) present a much greater and much more widespread threat in "relaying" attacks such as this.
  • It means "denial of service"...
  • Just in case you read this later, my mistake. The 29 byte UDP packet problem is still correct with a min transfer unit of 64 bytes, the smallest you can send is 64 bytes. Too much time looking at ATM : )

    Thanks for setting me straight.
    --
    Mike Mangino Consultant, Analysts International
  • > Seriously, when has Apple's reaction ever been anything but "We have no official comment at this time"?

    when they have something to say.
    apple is not going to comment until they know exactly what is going on and have a patch.

    if you'll notice and read some of the posts put up after yours, you'll discover that once apple did know what was going on and had a patch.. they commented and released the patch.

    as for the apachebench bit, i think they did comment very quickly. i seem to pretty clearly remember reading a technote at apple's website about it. in fact i think that was where i first saw it, linked from macnn. i searched the Tech Info Library just now (which may not be the same as teh technotes) and was not able to locate what i thought i rememebred reading, but i did locate http://til.info.apple.com/techinfo.nsf/artnum/n590 05
    which is a general OS X Server patch that seems to adress the apachebench problem.

    i remember when the ping of death became a problem, but it was long enough ago i can't remember how apple handled it.

    apple does not like to do anything unless they can be sure of what they're doing. they do not like releasing software before they think it's perfect. they do not like talking about unreleased software until they're certain it's ready to be talked about. they do not like to comment on things they don't know enough about to comment on correctly. this seems pretty reasonable to me-- at least, it's slightly better than vaporwaring and amplifying rumors based on information they haven't personally verified yet.
  • Apple has posted the TO Tuner 1.0 patch.
  • look, all of the distributed DOS systems require a machine to run on, which makes the fact that it can be used to flood pretty irrelevant compared to what else it can be used as.

    The OS9 thing is a networkcode issue, just like smurf attacks was. Whenever you design network code think about this: if the protocol being used does not use a handshake or in some other way verify the recipient, do NOT send large packets in response to small ones.

    UDP & ICMP/IP can be used for this sort of attack very easily. if you use a clever DNS request I'm sure you can get a packet back that is a lot larger than your request. connectionless protocols all have that flaw.

    On a last note though, this does not sound like a problem worth attention unless it responds to broadcast addrs.

  • Asymmetric traffic from MacOS 9

    MacOS 9 can be abused by an intruder to generate a large volume of traffic directed at a victim in response to a small amount of traffic produced by an intruder. This allows an intruder to use MacOS 9 as a "traffic amplifier," and flood victims with traffic. According to [3], an intruder can use this asymmetry to "amplify" traffic by a factor of approximately 37.5, thus enabling an intruder with limited bandwidth to flood a much larger connection. This is similar in effect and structure to a "smurf" attack, described in

    http://www.cert.org/advisories/C A-98.01.smurf.html [cert.org]

    Unlike a smurf attack, however, it is not necessary to use a directed broadcast to achieve traffic amplification.

    and

    Appendix A. Vendor Information Apple Computer We've reproduced the problem in our lab and we are working now to create a fix that can be easily distributed to our customers. The problem only affects customers running our most recent release of networking software on machines that are continuously attached to the internet.

    While most Macintosh customers are not affected by this problem, we are moving quickly to put a solution in place.

  • I know it's a joke, but I believe Apple's TCP/IP stack was developed by Mentat [mentat.com], so other OS's TCP/IP stack may also be vulnerable.
    --
  • BTW, since Windows is not open source, how do you really know it hasn't changed in 5 years? Is that another leap of faith also?

    Check out my reference to Phrack 54.
  • Umm, wrong. First of all, you can't send a 29 byte UDP packet. Second of all, it is carried on an ethernet frame to the cable modem which is 1500 bytes. You would need to have an incredibly thick pipe to actually do much damage. Remeber, the bandwidth is used at the ethernet layer. A 29 byte udp packet still uses 1500 bytes of bandwidth.
    --
    Mike Mangino Consultant, Analysts International
  • >What I'm asking is why don't more places prevent 1.1.1.1 from sending out a spoofed 2.2.2.2 packet?

    I'm afraid the only answer to that is ignorance. Nothing will break, after all - the protocol suite is intended to work with "real" addrs.

  • While you are right in saying that trin00/TFN is a big problem, on has to remark, as you say yourself, the attack you mention needs a cracked box.
    Show me ten boxes you have rooted (not your own please :)), and I'll give you the IP-Adresses of 20 Macs with OS 9.
  • I do tech support for a largeish ISP. Apparently there is something majorly wrong with Open Transport in OS 9.
    In fact we have not yet been able to get a single customer connected who is running it.
    All of you mac people using modems to connect to the net may want to hold off until they get this one fixed.
  • 1. Have you looked at the patents referenced, or have you merely decided that they're "obvious" based on the titles? 2. Did you even bother to look at the dates for the patents that you quote? I'd imagine that both of these patents were issued well before you were even born...
  • Let me go out on a limb here and assume that you're not flamebaiting, but honestly belive that MPS is somehow flawed. I don't think you truly realize the networking architecture that you're slamming here. Allow me to quote from Mentat's homepage:
    MPS is the native STREAMS on Apple Mac OS, Novell NetWare, Wind River VxWorks,Hewlett-Packard HP-UX, IBM AIX, Digital UNIX, and other many leading computer and embedded operating systems.

    And as for your conviction of the opinion (masquerading as "fact") that an intuitive, ergonomic, logically structured operating system is somehow flawed (as a client of course... Classic MacOS is a poor server), well... I sure wish you had some sort of coherent argument to back up your assertions, but hey, that's cool.

    We really ought to take this to email, to spare the rest of /., but since you're posting anonymously, I can't do that.

  • I heard about the MacOS X Server/Apache issue too. And if I recall, attempts were made to replicate the problem by numerous third parties, with no results. While I do not deny that an HTTP server locking up an operating system is inexcusable, the fact that few people seem to be able to replicate the issue makes it seem rather less virulent than ApacheBench crashing any MacOS X server it on which it was run.

  • See here [apple.com].

    Now, that didn't take long, did it?
  • I am warning you right now this is offtopic, but related.

    What methods are avaiable to stopping to slowing down this type of attack towards a Unix server? Would a firewall help, or could it be blocked at the router?

    This type of attack has been avaiable to crackers for awhile now, but I haven't seen a decent method of preventing, stopping, or even slowing down this type of attack? Any ideas?

    Could this be addressed in a ask Slash? It also burns when I take a piss, could this be addressed also?

    some of this is a joke, can you guess which?

  • I am just curious as to what issues you are having with your mac users. I also do mac tech for and ISP, and have not found a single problem in the few OS 9 boxes I have set up.

    Personally my b&w g3 running OS 9 that I am on right now via modem was a breeze to set up, and I haven't had a problem with it.

    Duck`

  • What does DOS stand for in this context?
  • The problem is that the script kiddies crack a few hosts sitting on T1s or better and then run the attack from there.

    You might check out CERT's [cert.org] paper on distributed DoS attacks [cert.org]. They don't go into great detail, but it does explain how the kiddies operate.

  • This type of thing (bandwidth amplification) is really not new at all, and it's for that reason that I'm a little surprised that OS 9 would be vulnerable. What do you get when you ping the broadcast address of a subnet using a spoofed IP? Bandwidth multiplication of up to a few hundred times. There have been router (and other) fixes for some time that prevent someone from being the middleman, but the picture of inattentiveness painted by this issue is not a pretty one, considering so many places are still vulnerable to being middlemen.

    Here's my question: Why aren't more ISPs filtering out IP packets that have a "From" address of a machine not covered by the ISP? If a router services an ip block of... say... 192.168.0.*, why doesn't it drop packets that don't come "from" that address? I suppose the big question is, why is address spoofing even an issue anymore? Is there some sort of roaming technology that might break? Can someone point out what would be back about this?

  • your comment is more or less correct - assuming that there are no filters on the routers along the way. however, the big deal is that, according to this advisory, the OS 9 can be made to reply with a packet 37.5 times the request. If this is true, the OS 9 can be used as a "traffic amplifier." In short, if an attacker using a T1 set things up properly she/he could possibly flood a machine with ~37 T1's worth of traffic - enough to take out almost any site. It would be far better if it always replied with less data (thus becoming a deamplifier), but oh well.
  • There I go again, believing things I read. :)
    I hadn't considered the size of the ethernet frame, but then again, I'm not the type of guy that has the knowledge to consider things like that.
    The reasoning not to just ping flood them from the rooted box is apparently this (from that link):

    If the attack computer sends 4000 40-byte trigger packets per second
    (bit rate less than 1.3 Mbps), the slave will send 4000 1500-byte packets
    to the target (bit rate 48 Mbps).

    The target organization (or organizations) is cut off from the Internet
    because it's connection, a 1.5 Mbps (million bit per second) T-1 or a
    45 Mbps DS-3 digital line is swamped with ICMP packets from forty
    different sources. Note that 30 different T-1 connections could be
    swamped by varying the return addresses in the trigger packets).

    Does this make sense? I'm no guru (or neophyte, for that matter), but it sounds like you're saying this guy's "byte amplification" is a load of hooey because the ethernet frame for the little trigger packet is still 1500 bytes, so you're using up your bandwidth whether or not you fill up the frame. (wonderful feeling to knowingly display a lack of knowledge on /. ;))
    I'd agree that this seems like an odd method to launch a DoS attack. Except that it's kind of cool (if it's true).

    -beme
  • by Anonymous Coward
    Some (most?) of us do filter packets that come into our routers that have a source address of our internal network. This is not the issue. The attacker is forging his source address to be the address of the target, and uses a 3rd middle man as the amplifier. So we have 3 people: 1.1.1.1 is the attacker, 2.2.2.2 is the middle man, and 3.3.3.3 is the target to be attacked. 1.1.1.1 sends spoofed 40 byte UDP packets to a macintosh at 2.2.2.2. The spoofed address is 3.3.3.3 (the target). The mac sends the 1500byte ICMP responses to 3.3.3.3 (the target).
  • Could anyone really take that guys site for real?
    "evidence of a conspiracy to shut down Internet Connections", yeah, right..
    It does seem on the page as if he is pro-mac, so I have no idea why he would post this.. but who knows what mental state he is in :)
  • I'm not sure about the quality of the stack in Win2K, but I remember reading that it had essentially an identical signature to BSD's. My theory is that the Win2K TCP/IP code is "inspired" by the BSD source code. So maybe that means it's actually decent.
  • Seriously, when has Apple's reaction ever been anything but "We have no official comment at this time"? Remember how long Macs were susceptible to the Ping of Death a few years back? Silence from Apple. ApacheBench crashing any MacOS X Server that it touched, possibly pointing to an architectural flaw? No comment. No offense to you, John (I'm not sure if you work for Apple or not), but Apple seems to be near the bottom of the list -- at least they're above Oracle -- when it comes to releasing critical information in a timely manner.

    Cheers,
    ZicoKnows@hotmail.com

  • Compounded with the fact that first you have to make a list of several Macs with the bug who's total bandwidth is at least equal to yours, otherwise you are being no more effective than a ping flood.
  • I am saying that since that the fingerprint is the same that this is the best comparison that we have. If Microsoft does not have to change the code, then they probably won't as reusing old code is more cost effective.

    From my own perspective: Quake 3 Arena runs at a lower ping under Linux than it does under Win 98. My pings (to my close local server) average around 60-100 ms under windows. They average 30-60 under Linux. Same hardware (I dual boot).

    There is also probably a good deal of junk in the windows stack. This is why there are net-accelerators for windows. Again, I get faster download speeds under Linux (Cable modem) than I do under Windows. True, it could be tied to something else, but what? Given the number of times that I have installed (and Re-installed) Windows, and the times that I have upgraded my Linux Kernel and distro over the past few years, the pings and downloads are always better under Linux. You are correct, I can't prove its the stack. I just have very strong suspicion that it is. Is that enough to base an argument on? Probably not. Still I would be interested as to your thoughts on what could cause the difference.

    Regarding the first response, I still don't see how Red Hat is an equivalent, they don't control the TCP/IP stack under Linux, Microsoft obviously does under Windows. Microsoft has had its stack attacked many times, and is slow to fix it. The same attacks have been levied at Linux (just as this Mac DOS attack is being discussed) and the fixes have been extremely fast.

    My question is what is your point? The original post was funny, especially to myself as I have dealt with both OS's for some time. Microsoft DID make a "donation" to Apple. AFAIK, Red Hat did not. (And why post as AC anyhow?)
  • What the summary doesn't mention is that Apple has already whipped up a patch (took them two days) and it should be available to the public soon.

    --
  • by SPorter ( 83284 ) on Tuesday December 28, 1999 @11:51AM (#1438110) Homepage
    John Copeland has 42 patents [gatech.edu] on things as obvious as "Functionally Static Type Semiconductor Shift Register with Half Dynamic-Half Static Stages" and "Magnetic Bubble Enhanced Propagation Pulse Write for Lateral Displacement Coding". I'm all for patents and all, but not for obvious ones like these. This is as bad as Amazon! I think we should boycott him!
  • Sounds like something's "majorly wrong" with your ISP, as I've set up dozens of OS 9 machines to connect to various dialups and haven't had any OT issues.
  • They did fix the cgi flaw in OS X Server quickly enough.
  • Real men use punch cards and a difference engine. Everything else is just kruft.

    Conscience is the inner voice which warns us that someone may be looking. [lemuria.org]

  • is this a stack issue, or a higher level software issue? the patch Apple offers is specifically for Open Transport 2.5.2 ...
  • People get connected, but then they get the unable to create network socket connection error from netscape.
  • I noticed the ping problem awhile ago, and UDP is just the tip of the iceberg. A SYN (sent to any port, closed or not) will also prompt unpatched MacOS 9 to send the 1500 byte icmp packet. Stranger still, the OS will send the ping to all connected hosts every 17-22 minutes, but at no regular interval. The data in the packet is empty. However Apple managed to let something this apparent slip beyond alpa testing is beyond me.
  • In short: Several products have been developed that use the delays and incongruities inherent to any TCP/IP stack to try and 'fingerprint' the OS. Nmap, for example, can tell the difference between Linux 2.0.xx, patched 2.0.xx, 2.1.xx and 2.2.xx. The TCP/IP stack only changed slightly between kernels, yet there is a discernable difference. None of these products, however, can sniff out one iota of difference between the Chicago, Win95, Win NT 4.0, Memphis or Win98 TCP/IP stacks. Why? They're the same! No change. Additional evidence: Notice how each and every one of the Microsoft OS's is/was vunerable to the same 'nuke' type attacks? This is very unlikely if they do not consist of the exact same code.
  • OS9 did run on the TRS-80 Color Computer, though FYI, it was third-party. And the developers (or whoever owns it now) weren't pleased by APple swiping the name.

    See http://ww w.macobserver.com/news/99/september/990903/microwa relawsuit.html [macobserver.com].
  • (sigh) I need to keep up with my TLA's. I spent 5 minutes trying to figure out why being able to emulate a PC command line interpreter using distributed clients on Mac OS9 was anything worth freaking out over.
    Sure, it's worth style points, but does CERT really need to know about it? :)
  • Remeber, the bandwidth is used at the ethernet layer. A 29 byte udp packet still uses 1500 bytes of bandwidth.


    I've read this comment a few times now. It is nonsense, ofcourse. Ethernet packet are variably sized.

  • by crayz ( 1056 )
    As a Blue G3 owner, I was trying to get info out of Apple about the G4 ROM block, and they kept telling me they couldn't comment on rumors. Finally, when I had kept asking for a while(and they would delete my posts), they contacted my ISP and bitched about me.

    Those tech support guys are bastards, especially Todd. And no one else at Apple will comment on anything either.

    If you want more info about this, I'd just stay tuned to sites like:

    www.macnn.com
    www.xlr8yourmac.com
    www.maccentral.com/forum/
    www.macfixit.com
    www.macintouch.com

    Apple may keep its mouth shut until it has a fix. Apple might even wait for MacOS 9.0.1 to release a fix(see www.appleinsider.com)
  • Alright, I've seen enough of this... "OS-9" [microware.com] is an operating system designed by Microware [microware.com] in the early 80's. It's an extremely good, small, fast RTOS. It's also Microware's registered trademark -- hell, it's the product's name! It ticks me off to see people automatically associate "OS-9" as MacOS 9.

    I'm now taking bets on how long before Microware wakes up it's lawyers.
  • OK, this all seemed very strange, but I still had doubts that a mentally healthy professor of a respected university would spread hoax. But this [gatech.edu] was just too much. Quote:
    Apple has developed a patch, but it must be applied by OS-9 Macintosh owners before New Years Eve to be effective.

    I guess someone has somehow acquired access to this guy's webpage and put all the BS there (like Mahir :)
  • Remeber, the bandwidth is used at the ethernet layer. A 29 byte udp packet still uses 1500 bytes of bandwidth.


    I've read this comment a few times now. It is nonsense, ofcourse. Ethernet packet are variably sized. And you can most certainly send a 29 byte UDP packet.

  • Does this work in older versions of the MacOS?

    No. As far as Macs are concerned, this bug is specific to the version of OpenTransport in OS9.0

  • The minimum ethernet frame is 64bytes. The actual UDP packet contains 29 bytes of data. Those bytes then get a UDP + IP header attached to it -- that's usually about 40 bytes. The ethernet card (driver, whatever) adds the ethernet MAC header (14 bytes?) and puts it on the cable...

    Every layer the packet passes through with add and remove any necessary padding for transmission. For example, if that 69 byte IP frame were to pass through an ATM (AAL5) network, it would need two 53byte ATM cells.
  • at least the microsoft poster was funny, being that it's slightly relevant to the topic... Microsoft did invest in apple... the joke is about the programmers...

    Redhat's done squat... so far as this discussion goes.
  • They've updated their statement [apple.com]:

    "Since CERT has posted their advisory this afternoon, it does appear to be something real. I still haven't been able to find any further internal information, but when I do, I will pass it along.

    John"
  • by waldoj ( 8229 ) <waldo&jaquith,org> on Tuesday December 28, 1999 @10:24AM (#1438140) Homepage Journal
    http://discuss.info.apple.com/boards/macos.nsf/424 f8fb007a848d1862564c60074f8f1/5B274CA6 954706958625685500635B28?OpenDocument [apple.com]

    "We have no official comment at this time.

    Remember, we have a policy of not discussing unannounced updates. Once I find out any further
    information, I will tell you what I can.

    For one thing, it smells like a hoax to me. First, there is already a product called "OT Tuner"
    from a third-party company (Sustainable Softworks), so we would be extremely unlikely to use
    this name. Second, we would never supply any kind of "patch" software to an outside party
    without making them sign a non-disclosure agreement. Third, most of the engineers were on
    holiday at the end of last week, and it is very unlikely a patch could have been developed and
    tested in such a short time without information going out internally within Apple (which hasn't
    happened).

    I'm not saying it is indeed a hoax, I'm just saying don't put a lot of validity to it until we know
    more.

    John Phelps
    Forum Leader - Apple Support Discussions"
  • by Asparfame ( 96993 ) on Tuesday December 28, 1999 @10:25AM (#1438142)
    In order to perform a worthy DOS though, you would need to

    a) Have a very long list of Mac's running OS9

    b) Send out a lot of UPD packets

    In fact, you would have to send out as many packets as the attacked server will recieve. So basically, you have to have enough bandwidth to withstand your own DOS attack. Of course it does have the advantage of hiding your IP, but it sounds no more effective than "ping -f".

  • by mangino ( 1588 ) on Tuesday December 28, 1999 @10:28AM (#1438143) Homepage
    Maybe I'm completely missing something, but can't you just send it an ICMP ping request with a forged source address and have it send the response? This doesn't sound like anything special. Maybe if we could get some more information about the type of ICMP packet that is sent this could be helpful.

    So normally, you send an ICMP response request packet (a ping packet) to a machine and it responds to you. This is a pretty simple concept. The problem is that you flood the connection with your ping requests. I believe ping floods are normally caused when you get the machine to respond on a broadcast or multicast address. If the mac just responds with a ping response, this isn't a very important discovery.

    However, there are other kinds of ICMP (Internet Control Message Protocol) packets. Maybe this isn't a straight ping request or ping response flood. Unfortunately, there isn't more information provided about it. Can someone post more information?
    --
    Mike Mangino Consultant, Analysts International
  • Is there something peculiar to OS9 that leaves it vulnerable to this attack? What about other OSs? Can they detect a spoof?

    Jazilla.org - the Java Mozilla [sourceforge.net]
  • by CynicX32 ( 34604 ) <Ryan@eristic.org> on Tuesday December 28, 1999 @10:31AM (#1438147)
    I mean, first the guy can't even properly spell OS 9 (there isn't a dash). Then he says that the attack can be easily perpetrated by people with root access to a large university system, as long as they can then erase all logs of their activity.

    Yup. Sounds easy as pie to me.

    Then there's some of his "proof", like the CERT email. From which he removes a paragraph with no indication what it used to say, and removes the PGP signature. It also merely talks about a completely different attack, and says "if we get time to look at this alleged OS 9 thing, we'll try."

    Just smells fishy to me.

    ryan
  • This page presents evidence of a conspiracy to shut down Internet Connections. Zero-hour is probably New Years Eve, EST.

    And how exactly is this more dangerous than trin00 / Tribe Flood Network? For those who haven't heard of trin00/TFN, it is networks of hundreds of r0043d machines on the Internet, each running daemons with the sole purpose of flooding any IP from widely scattered machines, all under the control of 5kr1p4 k1dd3z.

    I suppose if the trin00/TFN code were updated to support this new kind of DoS as an option, it could be bad, but a bug like this can not be easily exploited to disrupt the internet itself, since Macs make up such a small population of the "live" Internet.

    This is not to say that the DoS can't be launched against the MacOS 9.0 machines themselves, but the potential for widespread 1/1/2000 mischief is limited.
  • Additional evidence: Notice how each and every one of the Microsoft OS's is/was vunerable to the same 'nuke' type attacks?

    Nope. There was an "issue" with Win98 and one of the Win2K betas or RCs and IGMP floods. They'd cause a bluescreen in the affected versions of Win98 and Win2K, but didn't in Win95 or NT4.

  • Forever now, i've operated under the assumption that frame size is variable... Which is why all those utilities are available (for win and mac) that allow you to change your MTU (is that the right term... and is it the right term for this discussion?) depending on the speed of your connection - small for modems high for ethernet...

    So, couldn't you send the packetr to the Macs using a very small frame size and have them in return clog the pipe for you? It sounds that way to me.... maybe i'm wrong
  • If any of these script kiddies has a web server somewhere that they can see the logs of, then it'd seem much easier to just see where the macs are coming from, and send the attack through them... if nothing else, it would add an extra step to finding who perpetrated the attack.
  • If it actually exists (see above remarks from Apple themselves), it's most likely a bug in Open Transport.
    Because OT is totally modular, any bug fix/patch would be a nice small download, well under a Meg, unless Apple decides to roll the patch into OS 9.0.1, coming soon.


    Pope
  • Well, if it's not a hoax, the guy's site has some info pertaining to these questions.

    1) In his experiments, only macs running OS9 responded to the scans he ran. Easy way to gather a pretty big list.

    2) a 40 byte trigger packet results in a 1500 byte response, so you get a nifty little bandwidth multiplier there.

    The page to read is http://people.atl.mediaone .net/jacopeland/macattack.html [mediaone.net]


    -beme
  • CERT Advisory [cert.org]

    37.5x traffic amplication. Wheeeeeeee.

    Although that is incredibly dangerous, this guy is actually making a claim of an expected international y2k attack on the basis of two foreign port scans. hmmmm. Someone had a bit too much coffee.

    Anyhow, I can't seem to find any reference of this on Bugtraq. He appears to have only informed CERT and his local network admin.

    matt

  • Some (most?) of us do filter packets that come into our routers that have a source address of our internal network.

    Yes, and I would certainly call that a "good thing," but that's a little different from what I was asking. You're refering to preventing a spoofed 1.1.1.1 packet from entering the 1.1.1.1 network. What I'm asking is why don't more places prevent 1.1.1.1 from sending out a spoofed 2.2.2.2 packet? 2.2.2.2 isn't on that network, so why shouldn't packets heading out "from" those addresses be blocked? I'm trying to think of a legitimate reason for allowing these false from addresses in IP packets, but I can't at the moment.

  • by blukens ( 27693 ) on Tuesday December 28, 1999 @01:02PM (#1438184)
    Guess it's not a hoax, and I have to give props to Apple for the quick response...

    http://asu.info.apple.com/swupdates.nsf/artnum/n 11559

    Description
    OT Tuner 1.0 switches off an option in Open Transport that would cause a Macintosh to respond to certain small network packets with a large Internet Control Message Protocol (ICMP) packet. This update prevents Macintosh computers from being the cause of certain types of Denial of Service (DOS)
    issues.

    To install, drag the OT Tuner 1.0 file to the System Folder (the tuner will be put in the extensions folder for you). Then restart your Macintosh.
  • by plaidhat ( 130455 ) on Tuesday December 28, 1999 @01:04PM (#1438186)
    The Mac Resource Page had the best coverage of this DoS attack, imho. They cover it a lot better and in more detail than I could, so instead of repeating their words, I'll just post a link to them here: http://www.macresource.com/ [macresource.com]. Apple did indeed release a patch today by the name of "Open Transport Tuner". You can find it at the Apple Software Library (http://asu.info.apple.com/ [apple.com]) on the "Recent Changes [apple.com]" page.
  • by Sloppy ( 14984 ) on Tuesday December 28, 1999 @01:16PM (#1438188) Homepage Journal

    He's just jealous that they ended up not naming their OS after him.


    ---
  • by frankie ( 91710 ) on Tuesday December 28, 1999 @10:40AM (#1438191) Journal
    I defer to a recently-received email from Geoff Duncan, technical editor of Tidbits.com:

    *****

    Date: Tue, 28 Dec 1999 13:06:31 -0800
    From: Geoff Duncan
    Subject: Re: Mac DoS Attack

    While the attack outlined by Copeland is feasible, it's worth noting the 1500-byte ICMP responses he describes are not isolated to Mac OS 9, and are more-or-less standard practice in a number of networking implementations, regardless of whether those are based on Mentat's STREAMS. Macs running Mac OS 9 are by no means the only systems which demonstrate this behavior; in fact, I can easily make a number of dedicated routers behave the same way. If I were a cracker intent on causing damage with this sort of attack, why would I bother to locate Macintoshes on DSL or cable modem networks when I can utilize the same behaviors in thousands of routers all over the Internet, each of which is presumably easy to locate and has reasonable (or excessive) amounts of bandwidth at its disposal?

    The amplification attack Copeland describes involved gaining root access to a box with a big pipe - probably something running a flavor of Linux, Unix, or NT - and creating home-make forged packets. There are a number of potentially devastating attacks that can be launched under those circumstances that have nothing to do with Macs. TidBITS has been treated to a small selection of these sorts of attacks for the last several weeks. Calling for Mac OS 9 computers to be patched or taken off the net is not going to solve the problem or eliminate the feasibility of the attack Copeland describes.

    Also, Copeland's speculation that the datagrams he detected are probes pursuant to Macintosh-specific News Year's Eve attacks are best described as unsubstantiated speculation. At worst, they might be described as irresponsible. I would hope any further coverage this report gains in the Macintosh press will be more objective than what's currently playing on the standard "rumor" sites.

    *****
  • The purpose of this scheme, which I call a "Mac DoS Attack," is to generate a large amount of ICMP Internet traffic going to a specific target. This scheme can be replicated to attack many different targets, with little chance that the perpetrators will be caught. Phase I - Scanning The attackers run computer programs that sends UDP packets to every Internet address in the address ranges assigned to CATV cable modem and ADSL modem providers. Addresses that have Macintosh computers attached and operating will respond with a 1500-byte ICMP packet. These addresses are kept in a list for Phase 2. I will refer to the Macintosh computers at these addresses as "slaves."Phase 2 - Attack A computer at a location like a University is "root compromised." This means the aggressor group has used one of the many well-known techniques to gain the administrator password so they can load their own programs, which may be scheduled to run at a later time (like Christmas Eve or New Year's Eve). The compromised computer is given a list of addresses for 40 slaves, and the address of a specific target. The log files are erased so that no one will later be able to tell who installed the attack program. When the attack program starts running, it sends trigger packets in rotation to the forty or more slaves on its list. The source (return) Internet address is forged to be that of the target. The slaves then send a 1500 byte ICMP packet to the target each time they receive a 40-byte trigger packet. If the attack computer sends 4000 40-byte trigger packets per second (bit rate less than 1.3 Mbps), the slave will send 4000 1500-byte packets to the target (bit rate 48 Mbps). |-------------> Slave ------------>| Control |-------------> Slave ------------>| Computer ------->|-------------> Slave ------------>|-------> Target |-------------> Slave ------------>| | * * * | 4000 1500-byte 4000 40-B pkt/s 100 40-B pkt/s 100 1500-B pkt/s ICMP pkts/s to each slave from each slave = 48 Mbps This figure shows the process of "byte amplification." The target organization (or organizations) is cut off from the Internet because it's connection, a 1.5 Mbps (million bit per second) T-1 or a 45 Mbps DS-3 digital line is swamped with ICMP packets from forty different sources. Note that 30 different T-1 connections could be swamped by varying the return addresses in the trigger packets).

    Had to search the web site a little to find this, so I thought I'd post it to make people's lives easier. The problem I see with the theory above is that: what ADSL/Cable connection could support 48 Mbps of data from the Macs? I think there would have to be an AWFUL LOT of Mac slaves to actually swamp a DS-3 connection. In fact, I bet it isn't even possible.

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Working...