This is new Windows behavior as a result of reselt patch updates, specific patch has not been identified yet.

Fully Patched Microsoft stack now behaves as if vulnerable to CVE-2001-0183. Generally triggering Alarms of responding to invalid TCP/IP packets.

Instead of marking the bug resolved (as per design), would you mind providing feedback as to why this would be a design feature, and what are the advantages of such behavior?

Xavier:
I apologize for the incorrect resolution. This is definitely a bug and not by design. I went ahead and compared all the supported OS'es and found that Win2003 alone responds with a S+A in response to a S+F (the other cases of S+F+P, S+F+R and S+F+R+P behave correctly on Win2K3 as well).

That said, I would like to understand the source of your concern behind this bug. This is benign even if a little meaningless.

Thanks
Vivek

Hello Vivek,

I made some tests on different platforms this morning. All tests were performed on a confirmed open port and each target had its firewall deactivated. Furthermore, the tests were performed on the local network to avoid issues with routers, gateways, firewalls or any other network equipments that might interfere with the traffic.

Here are the results:

-> Windows 2000 SP4
* SYN-FIN: SYN-ACK
* SYN-FIN-PUSH: SYN-ACK

-> Windows XP SP3
* SYN-FIN: SYN-ACK
* SYN-FIN-PUSH: SYN-ACK

-> Windows 2003 SP2
* SYN-FIN: SYN-ACK
* SYN-FIN-PUSH: SYN-ACK

-> Windows 2003 R2 X64 SP2
* SYN-FIN: SYN-ACK
* SYN-FIN-PUSH: SYN-ACK

-> Windows 2008 SP1
* SYN-FIN: RST-ACK
* SYN-FIN-PUSH: RST-ACK

-> Windows 7
* SYN-FIN: RST-ACK
* SYN-FIN-PUSH: RST-ACK

1) According to those tests, Windows 2008, and Windows 7 are not affected by the issue.

2) Windows Vista, and Windows 2008 R2 were not tested and thus we can not confirm anything for these two platforms.

3) All current flavors of Windows 2000, XP, and 2003 are affected by the issue for both flag combinations SYN-FIN and SYN-FIN-PUSH.

4) As for supported platforms, last I checked Windows 2000 is no more supported but Windows XP and above are still supported assuming they operate the latest Service Pack.

5) As for why that is an issue, while performing security audits targets behave like if they were vulnerable to issues like CVE-2001-0183. Not only does this behavior generates false positives, but it also generates a sensible number of alarms on IDS systems.

Xavier:
Thanks for the detailed test results. It is strange that our results dont tally for Win2K3 SP2 in the SYN+FIN+PSH case. I have captures where such a segment receives a ACK+RST. The one difference I notice is that your test was on X64 while I did the test on x86. I will check to see if this is the difference. It would be great if you could attempt this test as well.

I looked into the CVE and I agree that such segments are crafted and never output by Windows under normal operation, i.e. Windows conforms to the robustness principle outlined in RFC 793. I also agree that it is reasonable for the IDS software to generate an alarm when it observes such a segment or a response to it (assuming it needs to reduce the noise).

Now typical network deployments consist of edge firewalls that could easily be configured to drop such crafted segments thus eliminating any false positives. Would this workaround suffice?

Now it is entirely possible that the edge firewall may itself be susceptible to this CVE and this would need to be adressed by the manufacturers concerned. I think this would be quite critical for them.

As such this one connection that was accepted by Win2K3 in response to this crafted packet doesnt really pose a problem to the Windows TCP/IP stack itself and doesnt worsen the security guarantees provided by the OS. Overall the OS can be relied upon to continue normal operation as far as TCP/IP is concerned in such a case.

If the workaround is not acceptable, could you please provide any supporting data on cost estimates incurred as a result of this bug? This will help in getting this bug fixed. Please also let me know if you believe there are security implications that I may have missed in my analysis.

Thanks
Vivek

Xavier:
Thanks for the detailed test results. It is strange that our results dont tally for Win2K3 SP2 in the SYN+FIN+PSH case. I have captures where such a segment receives a ACK+RST. The one difference I notice is that your test was on X64 while I did the test on x86. I will check to see if this is the difference. It would be great if you could attempt this test as well.

I looked into the CVE and I agree that such segments are crafted and never output by Windows under normal operation, i.e. Windows conforms to the robustness principle outlined in RFC 793. I also agree that it is reasonable for the IDS software to generate an alarm when it observes such a segment or a response to it (assuming it needs to reduce the noise).

Now typical network deployments consist of edge firewalls that could easily be configured to drop such crafted segments thus eliminating any false positives. Would this workaround suffice?

Now it is entirely possible that the edge firewall may itself be susceptible to this CVE and this would need to be adressed by the manufacturers concerned. I think this would be quite critical for them.

As such this one connection that was accepted by Win2K3 in response to this crafted packet doesnt really pose a problem to the Windows TCP/IP stack itself and doesnt worsen the security guarantees provided by the OS. Overall the OS can be relied upon to continue normal operation as far as TCP/IP is concerned in such a case.

If the workaround is not acceptable, could you please provide any supporting data on cost estimates incurred as a result of this bug? This will help in getting this bug fixed. Please also let me know if you believe there are security implications that I may have missed in my analysis.

Thanks
Vivek

Hello Vivek,

I just performed the same tests on Windows Vista are here are the results:

-> Windows Vista x64 SP1
* SYN-FIN: RST-ACK
* SYN-FIN-PUSH: RST-ACK

This shows that Windows Vista is not vulnerable to the issue.

As for the tests on Windows 2003, I did perform the tests on both x86 and x64 platforms. My results were details in my last comment and both platforms responded the same way with a SYN-ACK in response to packets with both SYN-FIN and SYN-FIN-PUSH. You will find attached to this bug report the Wireshark capture file for that session.

Remember that 1) the tests were performed on a confirmed open port and 2) each target had its firewall deactivated and 3) the tests were performed on the local network to avoid issues with routers, gateways, firewalls or any other network equipments that might interfere with the traffic.

The company I work for builds and provides to our customers proprietary Vulnerability Assessment solutions. The issue is not specific to our corporate environment but is triggered while scanning our customers. We do send crafted packets with the SYN-FIN flags set in order to test for CVE-2001-0183 (as an example). In this case all the platforms I reported as vulnerable to this bug reply with a SYN-ACK and this results in our solutions to report false positives. The fact that the targets also respond to our abnormal network packets, triggers a lot of alerts in the IDS installed at our customers. At this point deactivating those specific tests is not really an options since we could fail to report targets vulnerable to CVE-2001-0183 and a false negative is not a better option than a false positive. The workaround consisting of requesting that our customers install firewalls with specific rules is not an option for us as 1) there would be too many customers and 2) we do not control the budgets, teams, etc... that our customers need to address such an issue and 3) for some certification needs customers are required to white list our engines in their firewall configurations thus rendering them unable to act upon the network traffic between our engine and the targets.

Xavier:
I have put you in touch with the right people to get a QFE going for Win2K3 via email. The follow up will continue on that email thread.

Thanks
Vivek