Slashdot Mirror

http://msdn.microsoft.com/en-us/library/dd316910(VS.85).aspx A full API and set of tutorials is provided for other people to implement it.

Wordpad, Paint, Messenger, Visual Studio, the Office Suite and any program that wants to.

Yo Nominum, im really happy for you, and imma let you finish, but microsoft is one of the best trolls of all time!

Or they could just move 140 miles north to Canada.

There's already Microsoft presence there, and yes, this is development, not just a marketing office. Though it's rather minor (on the scale of hundreds of employees, not thousands).

Even XQuartz so that OSS stuff that uses X11 can run under OS X looking like OS X.

Does this include moving menu bars from inside the window to the top of the screen? GIMP sure doesn't. Or is that just a failing of the current GTK+ port?

Lets see Microsoft release an OSS version of XP minus some GUI bits.

Does Windows Academic Program come anywhere close to counting?

Oh, here's the Microsoft recommendation for AV for modern servers. http://support.microsoft.com/kb/822158

Excerpt:
Because domain controllers provide an important service to clients, the risk of disruption of their activities from malicious code from a virus must be minimized. Antivirus software is the generally accepted way to lessen the risk of virus infection. Install and configure antivirus software so that the risk to the domain controller is reduced as much as possible and so that performance is affected as little as possible. The following list contains recommendations to help you configure and install antivirus software on a Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, or on a Windows 2000 domain controller:

Ugh. A relatively new VM solution for the enterprise? No thanks. I'll stick with the "boring" tried and true methods not because they aren't interesting but because my employers know they can depend on me to use whatever works -- and that's why they pay me well. I would be jeopardizing my reputation by using something such as this without incredibly detailed testing.

It's good to be conservative in one's software choice (though many people on /. somehow forget it when discussing Windows -> Linux migrations). Personally, if I had VMware rolled out, and it worked for me, I wouldn't see any reason for a change; and I can't really think of any particular features of Hyper-V that would be convincing. But I'm no expert in either, so I'd rather not judge the people who made the decision here.

Besides, Xen and VMWare work so well why would I lock myself into any solution which requires Windows for the host OS?

Why not, if they're already running Windows servers throughout?

I don't want my host OS big and fat, needing a virus scanner etc. I want the tiny footprint of the other options.

I've yet to see a Windows server needing a virus scanner. It's kinda needed on your typical desktop Windows machine, and even then only because average users are clueless and prone to opening "Hot Naked Girls.jpg.exe" attachments and the like. If you run Windows with the same suspicious state of mind that's prevalent on Unix, you don't need it. And you definitely don't need it on a server (except for specialized solutions to scan incoming user mail on a mail server - but you'd want that regardless of server OS, so long as client machines are Windows).

You don't need a "big and fat OS" for Hyper-V either - you use Hyper-V Server, which is strictly a virtualization platform with minimal CLI-based UI for configuration, and no general Win32 compatibility. I won't claim that it's "tinier" than, say, VMware hypervisor, because I simply don't have the numbers - but then again, do you?

Not even that. OpenLDAP supports user-defined schemas. Active Directory doesn't. You have to go out and buy something if you don't like the stock set. Kerberos and one or more LDAP servers come standard with all the major Linux distros.

100% wrong, AD does allow schema customizations, using a simple command-line tool. Many applications do exactly this, not just Microsoft software. Developers steer clear of it, because a forest-wide schema change terrifies most PHBs, but it's actually rather trivial if you need it. Microsoft does request that if you sell boxed software that makes schema extensions, then you should register your schema IDs with them to prevent conflicts, but that's not enforced or anything.

Oh look.. it's even documented for you:
LDIF Scripts
http://msdn.microsoft.com/en-us/library/ms677268%28VS.85%29.aspx

What I especially like about AD is that once you've extended your schema (say by adding a few attributes to the User class), you can then write a management console add-in that adds an extra tab to the User property dialog box. Nifty.

Microsoft fixed the licening issue on Oct 1, 2006.
http://www.microsoft.com/windowsserver2003/evaluation/news/bulletins/datacenterhighavail.mspx

They specifically mention VMware ESX in the Microsoft article.

Why take the long road? Just get XP Mode from Microsoft. It's a free download and works pretty sweet (Win 7 Pro/Ultimate only).

I suppose one could type notes into some electronic gadget, but chances are that would strike people as overkill. Why bother? Besides, typing does not support the kind of random access editing of one's notes that cursive writing does (or if it does, it would take too long to do it in real time while the professor is talking).

May I introduce you to Microsoft OneNote?

So all of the following are now illegal in Brazil, since they can be used to assist copyright infringement: Firefox, Internet Explorer, Opera, Safari, Windows, Mac OS X, Linux, Filezilla, the cp Unix command, etc.

So all of the following are now illegal in Brazil, since they can be used to assist copyright infringement: Firefox, Internet Explorer, Opera, Safari, Windows, Mac OS X, Linux, Filezilla, the cp Unix command, etc.

You can do that in Windows, too. You just have to use software restrictions policies. They've been around in some form since at least Windows XP.

1. "don't want to" - this is not so, they made commitment to security several years ago and they removed all the insecure (and unsecurable) API calls from their software. For example, see this. Unfortunately strcpy is still alive and well in 3rd party products, and MS can't do much about that.
2. "don't know how to" - may be true sometimes, Windows is complex and nobody actually understands all the interactions.
3. "don't understand the need to do so" - this lawsuit clearly shows that at least now MS understands that their lack of security hurts them.
4. "no amount of money would be enough" - recent releases of Windows were kind of OK, so I guess they already spent most of the needed money and achieved most of achievable results.
5. "it's more lucrative to sell insecure systems" - MS doesn't sell systems, but it handles security incidents, often on its own dime.

I think the #2 is most important here. Windows is just too big to be fully understood. I'm sure there are tons of security-critical bugs in the code that is rarely used. It is very difficult to review and sanitize that code, especially if it "just works" and changes are likely to add bugs, not to reduce them. Additionally, more and more (percentage-wise) malware is distributed through social engineering, running .scr attachments, etc. - and that path is hard to close without going iPhone all the way.

In any case, the technical side of things is handled by one department and the legal side of things is handled by another department. I see no reason to pit them against each other. There are complaints about technical faults of the OS, but they should be addressed only to the development side of the house.

Microsoft's promise not to sue: http://www.microsoft.com/interop/cp/default.mspx

The promise covers several specifications, most importantly this:
C# Language Specification - Ecma-334, 4th Edition and ISO/IEC 23270:2006
Common Language Infrastructure (CLI) - Ecma-335, 4th Edition and ISO/IEC 23271:2006

I won't use Mono for that reason alone.
Guess what? You can use Mono now. yay!

I personally, don't care who wrote what and why. It works and it's available for use. To not use code because you think the programmer is immoral? That's awfully pious.

Could you clarify this a bit? You could boot Win95 to the DOS 7 prompt, type win and get into Windows, and then exit Windows - and be dumped to a command prompt.

Win9x booted real mode DOS initially and then loaded KRNL386.EXE to run full 32-bit protected mode Windows (similar to XP where NTLDR loads initially and sets up the basic environment before passing control to NTOSKRNL.EXE). Once loaded into protected mode the real mode DOS environment is essentially discarded. A really good Technet doc describing how it works can be found here.

but a freshly installed Vista + SP2 does

Does it? Are you guessing, or do you know? A clean install of Vista SP0 does not have any services listening through the firewall, and an nmap scan of the host does not find anything. I'd be shocked if this was changed for SP2, but I'll know once the install is done.

Support does not mean what you are claiming

Can you point me to Microsoft's definition of support, then? I couldn't find it with a brief search. Does it mean, "If we deign to release an update, you may download it?"

http://support.microsoft.com/gp/lifepolicy isn't really useful for my question, because it uses circular definitions. "Extended support" means you get "security update support" (this falls under a security vulnerability) but they never say what they consider "support" to mean.

Also, by not patching XP, they're saying that you shouldn't have any services listening on XP. I might be able to buy that argument if the same was said for Vista, however they patched Vista. Both are OS that are used for workstations and home support (i.e., not a server OS.) Both have similar services that can run (e.g., file and print sharing).

Also, the name-calling seems unnecessary. Why can't we have civil discourse anymore? If I'm misunderstanding the definition of "support", why not enlighten me? And no:

Support doesnt mean "microsoft is my bitch"

doesn't really count. You've told me what support isn't, not what it is.

ALSO - Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm [tcpipguide.com]

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx [microsoft.com]

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

The ONLY thing I am not certain of, is does this disallow SMALLER windows being negotiated, such as the setsockopt 0 uses in this type of DOS/DDOS attack. This I need feedback on, thanks.

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts

Thanks for clarifying this. In my opinion, a *defensive* use of software patents (to stop other people suing you with their swpats) is okay. But I also thought that Microsoft was aggressively suing makers of digital cameras and other devices that use FAT, even when those companies had not first sued or threatened Microsoft. Is that so?

I've looked around, and virtually all sources seem to agree that TomTom lawsuit was the first time FAT patent was brought into court (also, coincidentally, the first time a patent affecting any Linux code was actually demonstrated). However, there is a page on Microsoft IP web site which lists royalty fees ($0.25 per unit, to the max of $250,000), so I presume that at least some other manufacturers are paying for it - considering the low price, I can easily imagine it being cheaper to just pay than to defend in court, especially as the latter has no guarantees of success - and would be sued if they'd stop paying. So it's not black and white.

And seriously, "M$"? Is anyone still using that in 2009?

Microsoft's first product was a BASIC interpreter for the Altair computer. In the BASIC implementations common on Altair, Apple II, Commodore 64, and many other 8-bit home computers, names of string variables ended in $. For example:

10 LET M$ = "Microsoft"
20 PRINT M$;" licensed its BASIC interpreter to numerous microcomputer makers."
30 END

I see the usage of "M$" in posts as analogous to "thank $deity", which alludes to the syntax for naming a variable in Bourne shell, Perl, or PHP. At least to me, it carries a connotation of "the world might have been a better place had Microsoft stuck to its BASIC compiler and not ventured into monopolizing operating system market."

This is not true. It should be impossible to legally buy a copy of Windows XP.
Look this table:

http://www.microsoft.com/windows/lifecycle/default.mspx

Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?

Think about this, & comment please:

1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0

----

2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:

KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

----

3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

-----

4.) Tcp1323Opts, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0).

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2? Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

----

Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0? The ability to use setsockopt 0 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.

APK

P.S.=> I can't think of anything better than this but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts = 0 which STALLS "SLIDING WINDOW SIZES" (Tcp Scaling in other words), then, this attack (which seems like it is using the "Silly Window Syndrome" per the above) cannot work...

(As "setsockopt 0" cannot reset/renegotiate the TcpWindowSize & the sy

RFC1323 - TCP Extensions for High Performance: -> http://www.faqs.org/rfcs/rfc1323.html

Specifically, as regards "Window Scaling", & these pertinent quotes (& how Tcp123Opts = 0 shuts off ALL of these hi-performance TCP/IP options (slower, but sounds like a safety measure vs. this setsockopt 0 "silly windows syndrome" attack))

Please, read on:

"The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793). The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened

(Note that LAST bolded statement? THAT only "holds true", IF these RFC1323 options are 'turned on', first of all, & what turns them COMPLETELY off (@ the price of performance, perhaps, but not of safety vs. this "sliding windows scale/sliding windows/silly window syndrome" attack? Tcp1323Opts does))

http://www.speedguide.net/read_articles.php?id=157

Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)

Like SynAttackProtect = 2?

Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...

So, by setting them properly against this attack, by altering them, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters accordingly.

http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

You can nullify this attack it seems, because SynAttackProtect = 2 AND Tcp1323Opts = 0 (& using a set TcpWindowSize also) can stall out "sliding/scaling TCP Window Sizes", which this attack seems to exploit a vulnerability of via setsockopt 0 calls...!

APK

P.S.=> See my point now? Using Tcp1323Opts = 0, SynAttackProtect =2, & setting a TcpWindowSize to 64k (or whatever)? This setsockopt 0 type DOS/DDOS attack may be nullified it appears, because "sliding windows/tcp scaling" doesn't even take effect anymore, & this "setsockopt 0" seems to exploit it, via the "silly window syndrome" here -> http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter?

Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Hope you see my point... &, again, I'd like your "Feedback/Thoughts" on this as well - Thanks for your time, because I am trying to figure out a way, hopefully, to stall this attack on Windows 2000 rigs (I h

You mean like this? http://msdn.microsoft.com/en-us/library/cc313118.aspx

See subject-line above, & "SWS" was short for "silly window syndrome" ->

TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Again - please, read on & offer your thoughts after reading the above article especially & its KEY POINT/CONCEPT, quoted above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.

I am only looking for possible defenses for Windows 2000 users (MS stating PORT FILTERING will do it? Fine for workstations, but for servers that solicit connections?? Not so fine imo, as they have to offer connections, & THAT means they are "DOS'able"!)

Please, read on, offer your thoughts futhers on these points:

----

"Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

By "negotiated", don't/or do you rather, mean "Tcp Window Scaling", per the above about "Silly Window Syndrome"? I do know that SynAttackProtect, set to a value of "2", STOPS TcpWindowScaling... per this quote from MS:

SOURCE -> http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

----

Also: GlobalTcpWindow MAY NOT BE USEFUL HERE, since it is "deprecated", but?

The other parameter I noted apparently is, of TcpWindowSize, per your source no less here -> http://support.microsoft.com/kb/q263088/

----

"Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using http://support.microsoft.com/kb/q263088/ -

PERTINENT QUOTE: "To resolve this issue, set the TCPWindowSize value globally or use a value smaller than 64240 (this value is a multiple of the Ethernet Maximum Segment Size)." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

I never SAID it "hardened" the IP stack...

I figured it MIGHT help "mitigate" the setsockopt 0 that a 'badware' for DOS/DDOS would use to set a WindowsSize of 0, which IS the problem here, per the setsockopt 0 call, & what SynAttackProtect stops (sliding window sizes), & the fact that you can set that WindowsSize for Tcp via the TcpWindowSize parameter in the registry for TCP/IP's parameterizations...

Again - Thoughts/Feedback on these replies/points? Thanks for your time...

APK

P.S.=> BOTTOM-LIN

See subject-line above, & "SWS" was short for "silly window syndrome" ->

TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Again - please, read on & offer your thoughts after reading the above article especially & its KEY POINT/CONCEPT, quoted above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.

I am only looking for possible defenses for Windows 2000 users (MS stating PORT FILTERING will do it? Fine for workstations, but for servers that solicit connections?? Not so fine imo, as they have to offer connections, & THAT means they are "DOS'able"!)

Please, read on, offer your thoughts futhers on these points:

----

"Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

By "negotiated", don't/or do you rather, mean "Tcp Window Scaling", per the above about "Silly Window Syndrome"? I do know that SynAttackProtect, set to a value of "2", STOPS TcpWindowScaling... per this quote from MS:

SOURCE -> http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

----

Also: GlobalTcpWindow MAY NOT BE USEFUL HERE, since it is "deprecated", but?

The other parameter I noted apparently is, of TcpWindowSize, per your source no less here -> http://support.microsoft.com/kb/q263088/

----

"Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using http://support.microsoft.com/kb/q263088/ -

PERTINENT QUOTE: "To resolve this issue, set the TCPWindowSize value globally or use a value smaller than 64240 (this value is a multiple of the Ethernet Maximum Segment Size)." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

I never SAID it "hardened" the IP stack...

I figured it MIGHT help "mitigate" the setsockopt 0 that a 'badware' for DOS/DDOS would use to set a WindowsSize of 0, which IS the problem here, per the setsockopt 0 call, & what SynAttackProtect stops (sliding window sizes), & the fact that you can set that WindowsSize for Tcp via the TcpWindowSize parameter in the registry for TCP/IP's parameterizations...

Again - Thoughts/Feedback on these replies/points? Thanks for your time...

APK

P.S.=> BOTTOM-LIN

See subject-line above, & "SWS" was short for "silly window syndrome" ->

TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:

http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm

PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."

Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!

Again - please, read on & offer your thoughts after reading the above article especially & its KEY POINT/CONCEPT, quoted above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.

I am only looking for possible defenses for Windows 2000 users (MS stating PORT FILTERING will do it? Fine for workstations, but for servers that solicit connections?? Not so fine imo, as they have to offer connections, & THAT means they are "DOS'able"!)

Please, read on, offer your thoughts futhers on these points:

----

"Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

By "negotiated", don't/or do you rather, mean "Tcp Window Scaling", per the above about "Silly Window Syndrome"? I do know that SynAttackProtect, set to a value of "2", STOPS TcpWindowScaling... per this quote from MS:

SOURCE -> http://msdn.microsoft.com/en-us/library/aa302363.aspx

PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"

----

Also: GlobalTcpWindow MAY NOT BE USEFUL HERE, since it is "deprecated", but?

The other parameter I noted apparently is, of TcpWindowSize, per your source no less here -> http://support.microsoft.com/kb/q263088/

----

"Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using http://support.microsoft.com/kb/q263088/ -

PERTINENT QUOTE: "To resolve this issue, set the TCPWindowSize value globally or use a value smaller than 64240 (this value is a multiple of the Ethernet Maximum Segment Size)." - by Anonymous Coward on Tuesday September 15, @11:31AM (#29426941)

I never SAID it "hardened" the IP stack...

I figured it MIGHT help "mitigate" the setsockopt 0 that a 'badware' for DOS/DDOS would use to set a WindowsSize of 0, which IS the problem here, per the setsockopt 0 call, & what SynAttackProtect stops (sliding window sizes), & the fact that you can set that WindowsSize for Tcp via the TcpWindowSize parameter in the registry for TCP/IP's parameterizations...

Again - Thoughts/Feedback on these replies/points? Thanks for your time...

APK

P.S.=> BOTTOM-LIN

Actually that shouldn't matter a damn. XP is in extended support, which means: security update support is still active. It's completely bogus, and against their own terms to not offer a security fix, especially for something that suffers the same exact bug (likely from the same exact code) in a newer, fixed OS.

This is MS trying to string arm companies into paying them for upgrades.

http://support.microsoft.com/gp/lifepolicy

...do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability

Why couldn't other software have this 'listening service' and there for be vulnerable?

From the security bulletin, XP SP2/3 and XP PRO x64 SP2 are vulnerable (DOS). "This security update resolves several privately reported vulnerabilities in Transmission Control Protocol/Internet Protocol (TCP/IP) processing." - Just because one certain piece of software isn't vulnerable to this attack vector, doesn't mean another wouldn't...

The bug(s) are still there, sounds like they are just searching for reasons not to fix them, FTFA...

Although the two bugs can be exploited on Windows 2000 and XP, Microsoft downplayed their impact. "A system would become unresponsive due to memory consumption ... [but] a successful attack requires a sustained flood of specially crafted TCP packets, and the system will recover once the flood ceases."

directly from http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173 they're showing extended support into 2014. "extended support", according to their own faq, covers security fixes. i'm wondering at what point "inconvenient" to fix becomes "not technically feasible". unless they mean to say "impossible", but i find that hard to believe.

First and foremost: remember, we're talking about Windows 2000 and Windows XP below.

CVE-2008-4609 documents a problem with TCP stacks where established connections (meaning the initial SYN, SYN+ACK, ACK have already been experienced) can renegotiate their TCP receive window size to a small value (no idea what "small" means) or zero, the result being the number of available sockets on the machine becomes exhausted over time. Since TCP window sizes are negotiated, but not necessarily respected, there's really nothing one can do about this other than fix the stack, or allow added tuning for this. You can force window sizes (like you mention in your post), but that does not guarantee the remote end will honour them. This is Normal(tm).

CVE-2009-1925 documents a much more serious problem with the Windows TCP stack: "a remote code execution vulnerability exists in the Windows TCP/IP stack due to the TCP/IP stack not cleaning up state information correctly. This causes the TCP/IP stack to reference a field as a function pointer when it actually contains other information." There's nothing one can do about this one other than fix the TCP stack. End of discussion.

CVE-2009-1926 documents a problem with the Windows TCP stack where an already established TCP connection, with an agreed upon small (again, no idea what "small" is) or zero-sized TCP receive window, is closed with data still pending on the socket (likely shown as SendQ). When this scenario occurs, the Windows TCP stack never removes this entry from the state table. There's no indication or documentation from Microsoft as to whether or not this applies to sockets which have a) already gone through the FIN, ACK, FIN+ACK, FIN+ACK handshake, or b) is stuck in a "half-open" state where either the teardown handshake is severed/botched in mid-stream, c) is stuck in a "half-open" state elsewhere before socket teardown, or d) is stuck in a "half-open" state during RST.

I think you're focusing on CVE-2009-1926, since you have excessive focus on "half-open" connections, but then simultaneously you switch to focusing on SYN.

> TcpMaxHalfOpen
> TcpMaxHalfOpenRetried
>
> Also have to be considered as well (these determine how long before SynAttackProtect "kicks in", vs. the DOS/DDOS attack that could occur)

"Half-open" can refer to one of two things, depending on who you talk to: where from a source, SYN has been sent but has not received a SYN+ACK back (Windows calls this state SYN_RECEIVE, *IX calls this SYN_RECV) -- or -- a socket that has already been established but during tear-down never completes the full 4-way handshake (see above).

> P.S.=> Also, "hardcoding" the TcpWindowSize & GlobalTcpWindowSize settings in the registry in TCP/IP Parameters (see registry path above)
> SHOULD also help here also, for servers that can accept MANY connections from MANY clients, worldwide, as your specific constraints specify...

Please do not follow this advice. It has been stated by Microsoft in numerous KB articles that people should not use GlobalTcpWindowSize. The registry entry in question has been deprecated with the introduction of Windows 2000 and beyond; you should be using this.

Secondly, increasing/forcing/making static the TCP window size permitted does not "harden" the stack at all, or provide any direct effect on security. Instead, stop that and enable RFC1323 instead. There are numerous sites that describe this process. On servers in this day and age, RFC1323 is more or less mandatory, ideally if you're serving large content (greater than 64KB). Here's some links that describe RFC1323 in Windows:

http://searchnetworking.techtarget.com.au/tips/27055-How-to-use-TCP-RFC-1323-to-improve-Windows-XP-s-network-performance
h

The problem with all these analogies is Microsoft DID put a long warranty on XP, and SP2 is still covered.

http://support.microsoft.com/lifecycle/?LN=en-us&x=8&y=10&C2=1173

So the analogy here is, you buy a car. The manufacturer offers a 15 year warranty. 10 years in they find a flaw, they don't fix it and instead tell you to take it to a third party mechanic for a workaround at which point you find some lawyers and sue their contract breaching butt into next year.

For some unfathomable reason, MS rates remote code execution as a LOW impact problem for XP.

But that's not what they're doing! There is no remote code execution vulnerability on Windows 2000, XP, or Server 2003. Only Vista and Server 2008 are susceptible to remote code execution. This is a Denial of Service vulnerability on NT 5.x systems, and you have to have the firewall disabled (and, indeed, no stateful hardware firewall at all) in order to be vulnerable.

The details are here:

http://www.microsoft.com/technet/security/bulletin/ms09-048.mspx

It's fine to criticise Microsoft for not releasing a patch for XP, but let's at least get the facts about the vulnerability straight, first, yeah?

Whatever happened to MS's lifecycle support policy?

From their site:

Microsoft will offer a minimum of 10 years of support for Business and Developer products. Mainstream Support for Business and Developer products will be provided for 5 years or for 2 years after the successor product (N+1) is released, whichever is longer. Microsoft will also provide Extended Support for the 5 years following Mainstream support or for 2 years after the second successor product (N+2) is released, whichever is longer. Finally, most Business and Developer products will receive at least 10 years of online self-help support.

Take a look

Considering XP was released on Dec 31 2001, I'd say they're still 'on the hook' until 2011. They even say "5 years or 2 years after the successor product [Vista] is released, whichever is longer". That makes it 2012. Or "2 years after the second successor product", whichever is longer (2011). And that's just the Mainstream support, they say they'll continue with "security patches for 5 years" after mainstream support fades. I would consider remote code execution a security risk, guess Microsoft feels differently.

I say give 'em a month, tops, and then there will be a patch (or news of a coming patch) for Windows XP.

Now would be a terrible time for Microsoft to alienate all those big corps that have XP and force them into another OS, if they want to keep their customers.
It'd be great for everyone else, as customers may start looking into things they would never have considered otherwise, such as various open source operating systems, and the necessary apps it would take to keep them going in their workflow, post-transition.

The way it looks is, some people (usually companies) will view this as a threat from Microsoft that reads: "Upgrade if you want protection."
Some of them in this group will obediently upgrade to Fista or 7.
Some of them will reluctantly upgrade to Vista or 7.
Some of them will stay with XP and find other ways to secure themselves.
Some of them will [cross their fingers and hope|pray] that Microsoft changes their mind and offers a patch.
Some of them will be offended and migrate to another OS outside of Big Red Robotland.
And of course, some of them will feel that litigation solves everything, and want to take MS to court for "refusing to patch an OS that is in such widespread use" (or) "intentionally posing a security risk".

Refusing a patch like this, in my humble opinion, isn't something you want to do until a few months after your new OS lands, at the bare minimum. That way, you've already got people migrating.

XP's patching lifecycle isn't up yet, from what I can see here, though: XP SP2 should be good until July of 2010, and SP3 should be good a bit longer than that, so I'm surprised no-one has really called 'em out on that.

Here you go. Extended support is well into 2014. Mainstream support has already ended though.... Which is very strange considering XP is still sold with netbooks.

I guess these guys did not read: http://support.microsoft.com/gp/lifepolicy XP extended support goes thru 2014 and supposedly covers security fixes. I would think this counts as a security fix.

January 31st, 2009, looks like. That'd be what, 8 months back? http://www.microsoft.com/windows/lifecycle/default.mspx

The DOS/DDOS possible via the latest weakness in Windows 2000's IP stack @ least (uses RDR20.DLL as the LSP (layered service provider) vs. MSWSOCK.DLL (the LSP used in XP/Server 2003 onwards, by way of comparison, & this is where I think the problem lies largely, as it is the "most radically different part" of the IP stack in Windows 2000 vs. the more current builds of Windows that I could see @ least)?

WELL - That's taken care of by the SynAttackProtect setting here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

What does it do??

http://msdn.microsoft.com/en-us/library/aa302363.aspx

Description: When SynAttackProtect is enabled, this value specifies the threshold of TCP connections in the SYN_RCVD state. When SynAttackProtect is exceeded, SYN flood protection is triggered.

TcpMaxPortsExhausted
TcpMaxHalfOpen
TcpMaxHalfOpenRetried

Also have to be considered as well (these determine how long before SynAttackProtect "kicks in", vs. the DOS/DDOS attack that could occur)

This SynAttackProtect registry value causes Transmission Control Protocol (TCP) to adjust retransmission of SYN-ACKS. When you configure this value, the connection responses time out more quickly in the event of a SYN attack (a type of denial of service attack).

2: Set SynAttackProtect to 2 for the best protection against SYN attacks. This value adds additional delays to connection indications, and TCP connection requests quickly timeout when a SYN attack is in progress. This parameter is the recommended setting.

NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows

-----

IIRC? This is called the "Silly Window Syndrome", & this is a way, in theory, around it... & iirc, "Scalable Windows", via setsockopt API calls from an attacker are what the problem is here anyhow & this ought to 'stall it'... thoughts/feedback?

APK

P.S.=> Also, "hardcoding" the TcpWindowSize & GlobalTcpWindowSize settings in the registry in TCP/IP Parameters (see registry path above) SHOULD also help here also, for servers that can accept MANY connections from MANY clients, worldwide, as your specific constraints specify...

Thus, effectively stalling the ability to use TcpWindowScaling is stopped by SynAttackProtect too, so an attacking system/app sending a setsockopt of 0 for this SHOULD also be nullified, on a server also...

(However/Again - Workstations are easily taken care of , vs. servers, just by what I wrote up above either by PORT FILTERING)

IP Security Policies, which can work on ranges of addresses to block, OR, single systems as well you either ALLOW or DENY to talk to your system, still can help also... vs. a DDOS though? SynAttackProtect is your best friend here... you'd use netstat -b -n tcp to see which are held in a 1/2 open SYN-RECEIVE state, & BLOCK THOSE FROM SENDING YOUR WAY (or just by doing it in a router or routing table)... takers anyone, on these thoughts (especially for Windows 2000)?

Thanks for your time... apk

Fdisk /mbr ?

http://support.microsoft.com/kb/69013

Internet Explorer is not an integral component of the OS, and it is removable in Windows 7.

It has been an integral component for as long as I have used Windows, and Windows 7 isn't out yet. Sure, if you want MacGyver your system and thereby void any kind of support you may have received from either Microsoft or a vendor, sure go ahead. But there is no way to go to Add/Remove programs, remove Internet Explorer, and have it actually removed (in XP it just removes the desktop icon and start menu entry; I haven't bothered with Vista). To me, that makes it an integral component.

Since Messenger is an optional component from Live Essentials

Uh, Messenger is installed by default, and, again, you can disable access to it, but you can't remove it, at least not easily. And Media Player is the same. I guess you can actually remove it now (you used to not be able to), but it is still not a trivial process, although I will concede it is easy enough if you are determined and know what you are doing.

Also Windows Update isn't dependent on IE.

Really? Do tell. How do you get your updates from windowsupdate.com in Firefox? What's that? You can't because you need ActiveX? Sure the background updater utility will run without IE, but you are missing at least half of the functionality you get if you go directly to the website, which is what I prefer to do.

Anyway, all the nitpicks aside, the original point was that Microsoft doesn't "just bundle software like everybody else." They package their own software in a way that locks you in and competitors out. If that's what they want to do, fine, I avoid Windows as much as I can so I don't care. But then the reputation they get as a result is their fault, and they can't complain about people being biased against them. People are naturally suspicious and untrusting of anything Microsoft may try to do because they have a history of being entirely self-serving. That's the PR problem they now have to deal with.

Is that true even when the sound is already there? (Example: data urls?)

Internet Explorer limits data URIs to 32 KB, which is worth 24 KB after base64 decoding. Good luck fitting background music in that, unless perhaps it's MIDI. Besides, data URIs in Internet Explorer cannot contain sound, only images. And yes, some games do need to precisely synchronize rapid volume changes to background music; the canonical example is Guitar Hero, which mutes the sound when the player misses notes.

Only if you don't know how to concatenate them together for production.

There may be limitations in what can be concatenated. For example, textures used as CSS sprites can't be scaled.

Only if the browser doesn't know how to make multiple requests at once.

Have you any evidence that Internet Explorer does "know how to make multiple requests at once"?

Since the automated test suite is a description of what should happen, and what it means for the program to work, you're basically talking about moving all of the bugs to the spec level.

Then the bugs are in the translation of the spec from English to code in the tests, just as they would be in the translation of the spec from English to code in the actual product.

Hmm, I don't remember Halo 2 using that

What irks me is that Halo 2 is also an album by Nine Inch Nails, yet Halo 2 the game doesn't support custom soundtracks.

The maximum throughput of the Xbox DVD drive is 6.6 MB/s -- my Internet can do that

Nobody I know in Fort Wayne, Indiana, a city of 200,000 people, has over 50 Mbps Internet to the home.

The worst effect was "popup" or something like that

Where an enemy pops up and kills the player's character before the enemy's texture finishes downloading. Players do not appreciate that.

Is that true even when the sound is already there? (Example: data urls?)

Internet Explorer limits data URIs to 32 KB, which is worth 24 KB after base64 decoding. Good luck fitting background music in that, unless perhaps it's MIDI. Besides, data URIs in Internet Explorer cannot contain sound, only images. And yes, some games do need to precisely synchronize rapid volume changes to background music; the canonical example is Guitar Hero, which mutes the sound when the player misses notes.

Only if you don't know how to concatenate them together for production.

There may be limitations in what can be concatenated. For example, textures used as CSS sprites can't be scaled.

Only if the browser doesn't know how to make multiple requests at once.

Have you any evidence that Internet Explorer does "know how to make multiple requests at once"?

Since the automated test suite is a description of what should happen, and what it means for the program to work, you're basically talking about moving all of the bugs to the spec level.

Then the bugs are in the translation of the spec from English to code in the tests, just as they would be in the translation of the spec from English to code in the actual product.

Hmm, I don't remember Halo 2 using that

What irks me is that Halo 2 is also an album by Nine Inch Nails, yet Halo 2 the game doesn't support custom soundtracks.

The maximum throughput of the Xbox DVD drive is 6.6 MB/s -- my Internet can do that

Nobody I know in Fort Wayne, Indiana, a city of 200,000 people, has over 50 Mbps Internet to the home.

The worst effect was "popup" or something like that

Where an enemy pops up and kills the player's character before the enemy's texture finishes downloading. Players do not appreciate that.

Because that leads to dependency hell, and that leads to horrible user experience.

Hurry, better tell Valve! And maybe Microsoft, too, while you're at it! Or Apple, for that matter -- they love frameworks, as long as it's one they shipped with the OS.

Seriously, Linux has solved this dependency issue with package managers for decades. Contrary to popular belief, it's trivial to support multiple versions of a library. And with the App Store, no one can claim installation as a problem -- the App Store can easily be thought of as a package manager that only supports the official Apple repository.

I'm unsure the mechanism used by Mono but when programming .NET on Windows there is a utility -- named ILMerge -- which allows multiple assemblies including Framework assemblies (dlls) to be compiled into one executable file; allowing a .NET app to without the need for a Framework's file to be spread about, kind of erasing the fact a Framework exists.
(I.E. http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx )

Also on the Windows side the Common Language Runtime (CLR) of the .NET Framework is always needed to interpret the Microsoft Intermediate Language Code (MSIL) "byte code" which is the result of explicit compilation of any .NET application's source code files (C#, VB.NET, COBOL.NET, IronPython, etc). This is a sort of on-the-fly compilation or translation to machine code that occurs as needed.

Even when a native executable for the Windows machine is generated by the ngen.exe utility, in order to bypass MSIL translation at runtime,
(I.E. http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.71).aspx ) ...the CLR is still required to manage the native executable (memory management, garbage collection, security, type enforcement, etc).

Much C# code is compiled in managed mode (requires management by the CLR) and I'm sure the C# implementation for the iPhone would express this simplified programming model too. However I'd be interested to know what Novell/Mono team does with the CLR in the iPhone given the fact Apple does not like frameworks, interpreters or compilers. Does Mono compile the CLR feature into iPhone app, or get rid of it in favour of C# on top of a different concept, or something else?

I'm unsure the mechanism used by Mono but when programming .NET on Windows there is a utility -- named ILMerge -- which allows multiple assemblies including Framework assemblies (dlls) to be compiled into one executable file; allowing a .NET app to without the need for a Framework's file to be spread about, kind of erasing the fact a Framework exists.
(I.E. http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx )

Also on the Windows side the Common Language Runtime (CLR) of the .NET Framework is always needed to interpret the Microsoft Intermediate Language Code (MSIL) "byte code" which is the result of explicit compilation of any .NET application's source code files (C#, VB.NET, COBOL.NET, IronPython, etc). This is a sort of on-the-fly compilation or translation to machine code that occurs as needed.

Even when a native executable for the Windows machine is generated by the ngen.exe utility, in order to bypass MSIL translation at runtime,
(I.E. http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.71).aspx ) ...the CLR is still required to manage the native executable (memory management, garbage collection, security, type enforcement, etc).

Much C# code is compiled in managed mode (requires management by the CLR) and I'm sure the C# implementation for the iPhone would express this simplified programming model too. However I'd be interested to know what Novell/Mono team does with the CLR in the iPhone given the fact Apple does not like frameworks, interpreters or compilers. Does Mono compile the CLR feature into iPhone app, or get rid of it in favour of C# on top of a different concept, or something else?

Also, using C# is not THAT much better than the native objective-c

Excuse me? C# and .NET take the same approach as Java which is to provide the most powerful general purpose programming language + massive class library of common functionality possible (C# and .NET which allows any language to compile to the CLI assembly are arguably even more powerful than Java right now). C# and .NET are definitely MORE powerful than objective C in a general purpose sort of way (objective C might have more depth in specific targeted areas like GUI widgets, but the breadth of massive frameworks like C# and Java is truly vast). As for the memory management in C# and .net languages, you have to know a bit about garbage collection, finalization, and the IDisposable interface (which enables the "using" keyword syntax) when dealing with "unmanaged" resources (which require manual destruction, usually because they are outside the managed heap maintained by the .NET framework).

The major difference is due to the fact that it's an M$ product it's APIs aren't open

  Is that so?

  they're buggy and overall the devices run slower and are less customizable.

Care to share an example? Sounds like you have plenty... or are you just recycling wrong, out-of-date groupthink?

Not the GP, but I have two (both on Sprint)

A) Moto Q9c. I thought this was the worst POS phone I ever put my hands on, with slow speeds, lockups, and misfeatures, so I stupidly reupped and got

B) Palm Pro (Treo 850e). I was wrong. This makes the Q9c look like a miracle of modern fucking engineering. All the problems of the Q9c, and more, including the fact that some genius decided a phone doesn't need a fucking power button, so you have to open the batter compartment and hard reset whenever WinMo decides to shit itself, which it does... often... at the worst possible times...

Or to be exact and factually correct: Vista SP2