full-disclosure - Windoze almost managed to 200x repeat 9/11

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: bkfsec at sdf.lonestar.org (Barry Fitzgerald)
Subject: Windoze almost managed to 200x repeat 9/11

joe wrote:

>Nod. Some knucklehead used GetTickCount or clock() for their app and had no
>clue about datatypes and overflows and range of possible values and some
>people go off on Windows.
>
>I was helping someone in the public newsgroups with a similar issue.
>"Experienced" 10 year c coder who didn't understand why a long value would
>go negative and start counting down... He could have been coding for Windows
>or anything else. Unfortunately he chose Windows so his app contributes to
>people thinking Windows doesn't work. 
>
>The state of programming right now is like the state of the roads in
>Michigan. Mostly in disrepair and everyone blaming the weather instead of
>poor road building skills. In the meanwhile the Dept of Transpotation keeps
>hiring inexperienced road workers for some poor salary and using lowest
>bidder to build the roads and expecting them to miraculously get better.
>
>  
>
Where issues like this relate to the OS is in the fact that the OS 
itself shouldn't be brought down by a poorly designed app.

Of course, you can shoot yourself in the foot in any OS, but an overflow 
in a local app should never take down the kernel.  Unfortunately, memory 
management in MS Windows (though it's gotten better over time) is still 
not up to par and that is what causes a number of these issues.  Not to 
mention poor system architecture and design on the part of MS.

Was it MS Windows that actually held the code that brought the system down?

Well, that depends on how far down you want to drill and where you place 
the burden of OS stability.  If you place it on the OS, then Windows is 
fair game.  If you place the burden of OS stability on the app, then 
you're foolish and don't understand OS design concepts.  :)  (said in 
jest, but then, so is most truth)

The article doesn't make the situation entirely clear.  Did the app 
intentionally restart the system and foul it?  Did the restart occur 
because the app crashed?  I'm skeptical because technical details like 
this are usually confused, mislabeled, or misreported... even 
(especially?) in tech rags.  So, who holds the burden in this case 
depends on the answers to the questions above.

                -Barry