Well, they obviuously have rewritten their stack here. After all, who wants old bugs? *New* bugs are what the world needs -- Warning: 10 days have passed since your last Windows reinstall.
> Well, they obviuously have rewritten their stack here. > After all, who wants old bugs? *New* bugs are what the world needs
This issue did not occur on Windows XP.
Installation of Service Pack 1 and/or security updates had no effect in regards to resolve the random crashes.
To execute either the sample program or the route-add command, the user has to be member of the Network Configuration Operators group or the Administrators group.
Since this buffer overflow overwrites kernel memory, it could be possible that members of the Network Configuration Operator group exploit this and take control over the operating system without any restriction.
Not much impact, though:
Impact ----------------------------- 1. When adding a route entry to the IPv4 routing table using the method CreateIpForwardEntry2 and passing an illegal value greater than 32 [2] for the destination PrefixLength member in the DestinationPrefix structure contained in the MIB_IPFORWARD_ROW2 structure [3], kernel space memory is being corrupted resulting in random blue screen crashes. ...
In other words, a SNAFU <chuckle>.
This impact is worse, though:
2. In addition we were able to reproduce this issue without the sample program, using the built in "route add" command. It seems the "route-add" uses the same method as our sample program, hence creates the same buffer overflow when calling it with an illegal value for the network mask. The syntax we used in the command line is as follows:
route add 1.2.3.4/240 4.3.2.1
This buffer overflow could be exploited to inject code, hence compromising client security.
Ay yi yi.
What does that command do on Linux?
# route add 1.2.3.4/240 4.3.2.1 route: netmask 0000ffff doesn't make sense with host route Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables . . .
-- <rebelpacket> hey, quick question, is there any way to speed up the performance of uquake-x11? <Deek> rebelpacket: If you want to accelerate it, throw it harder.
>> Well, they obviuously have rewritten their stack here. After all, >> who wants old bugs? *New* bugs are what the world needs
> Serves them right for being BSD Pirates ;)
Serves BSD developers right for using such a lax license.
OTOH it wasn't they who screwed up the Vole's fork. Perhaps Microsoft would be better switching back to the current upstream version. In fact they should probably do that with their whole networking stack, since they clearly don't have the first clue about networking at all.
.---- | "At the time, I thought C was the most elegant language and Java | the most practical one. That point of view lasted for maybe two | weeks after initial exposure to Lisp." ~ Constantine Vetoshev `----
It was there for 2 years leaving "Debian server" totally open to anyone you could be bothered to hack in if they had sshd running.
-- "Of course, by the time Gnash gets its act together, we'll probably all have to start all over again with Silverlight (or Moonlight)." -- The Ghost In The Machine <ew...@sirius.tg00suus7038.net> in comp.os.linux.advocacy
> It was there for 2 years leaving "Debian server" totally open to anyone > you could be bothered to hack in if they had sshd running.
Oh, looky looky: Hadron Quark, the "true linux advocate", deflecting a real bad windows bug by pointing to a debian bug *and* implying it is a "linux bug". In the vain hope that somehow, magically, this windows bug might look somewhat less bad
Pray tell, liar Hadron Quark, which *other* distros had this bug? Be precise. While you're at it, explain why Debian, your "distro of choice" (if one is dumb enough to believe your claims), had this bug and no other distro had. Might it have to do with a really idiotic decision on the part of the debian maintainers?
So, why exactly is this a "linux bug", "kernel hacker" Hadron Quark? -- You're genuinely bogus.
> Well, they obviuously have rewritten their stack here. > After all, who wants old bugs? *New* bugs are what the world needs
You know better than this, Peter. By COLA standards, this doesn't count as a serious bug, since it appears to only allow a local, privileged, user to either DoS himself, or escalate privileges.
At least, that's the story when such bugs are found in Linux (which happens several times a year for the kernel, and several times a month if you include libraries and applications).
>> Well, they obviuously have rewritten their stack here. >> After all, who wants old bugs? *New* bugs are what the world needs
> You know better than this, Peter. By COLA standards, this doesn't count > as a serious bug, since it appears to only allow a local, privileged, > user to either DoS himself, or escalate privileges.
> At least, that's the story when such bugs are found in Linux (which > happens several times a year for the kernel, and several times a month > if you include libraries and applications).
It does not matter if it is local or remote. What *does* matter though that those incompetent monkeys at MS failed to do even so much as a cursery check on values. How much more of such time-bombs did they hide in their shiny all new Vista? -- Another name for a Windows tutorial is crash course
In article <492a548d$0$31342$9b4e6...@newsspool4.arcor-online.net>, Peter Kohlmann <peter.koehlm...@arcor.de> wrote:
> It does not matter if it is local or remote. > What *does* matter though that those incompetent monkeys at MS failed to do > even so much as a cursery check on values. > How much more of such time-bombs did they hide in their shiny all new Vista?
How is this different from when Linux kernel coders fail to check values? E.g.,
Tim Smith <reply_in_gr...@mouse-potato.com> writes: > In article <492a548d$0$31342$9b4e6...@newsspool4.arcor-online.net>, > Peter Kohlmann <peter.koehlm...@arcor.de> wrote: >> It does not matter if it is local or remote. >> What *does* matter though that those incompetent monkeys at MS failed to do >> even so much as a cursery check on values. >> How much more of such time-bombs did they hide in their shiny all new Vista?
> How is this different from when Linux kernel coders fail to check > values? E.g.,
>> maybe you should switch to Linux? Just make sure your ssh keys are not >> compromised ....
>Oh, looky looky: Hadron Quark, the "true linux advocate", deflecting a real >bad windows bug by pointing to a debian bug *and* implying it is a "linux >bug". In the vain hope that somehow, magically, this windows bug might look >somewhat less bad
On Mon, 24 Nov 2008 11:46:32 +0000, Black Dragon wrote: > 7 wrote:
>> Micoshaft asstroturfing fraudster pounding the sock Black Dragon wrote >> on behalf of Half Wits from Micoshaft Department of Marketing:
>>> 7 wrote:
>>>> BSD Pirates ;)
>>> Idiot.
>> BWAHAHAHAHAHAHAHAHAAAA!!!
>> You knowledge challenged idiot and fool!
> "BSD Pirates" implies BSD licensed software was stolen. So tell us > (tinu) oh monument to Linux Advocacy, how exactly does one "steal" > something that is given away for free?
Wasn't that the whole foundation of the SCO suit? :)
>>> Well, they obviuously have rewritten their stack here. >>> After all, who wants old bugs? *New* bugs are what the world needs >> How quaint... Thanks MicroSoft...
> maybe you should switch to Linux? Just make sure your ssh keys are not > compromised ....