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
| ||
|
Message-ID: <20040122154558.GA343@ngolde.de> From: nion at gmx.net (Nico Golde) Subject: Old school applications on the Internet (was Anti-MS drivel) Hallo Bill, * Bill Royds <full-disclosure@...ds.net> [2004-01-21 13:06]: > What you describe is actually one of the reasons for some of the flaws in > MS software. It was built with the assumption that the only machines on the > network that it would communicate with were other MS boxes. The network was > a LAN only ( why it was called LAN Manager). The flaw that allowed > Msblaster/Nachia last summer was one of these things. The software was > written assuming the an RPC caller process would "play nice" and never send > an invalid NETBIOS name for any machine. MS written software never did. So > the called server never checked on name size since there was no need to and > the caller always checked :-). When a worm ignored these agreements, we got > MSBlaster. Malware does not "play nice". It does not even play badly > accidentally. It deliberately tries to do damage. So the stakes for writing > software are much much higher than they were when DOS/Windows was originally > written. Windows 95 was written with the assumption that it would only be > used in a LAN. Bill G's belated discovery of the Internet (and the bolt-on > TCP/IP stack for Windows 95) has led to much of our security nightmare. > Windows 9x was never designed for an open network and the requirement to > have Windows NT/2000/XP/2003 compatible with the older versions has > prevented these from truly being Internet aware at the core. > Most old school software and its QA was attempting to ensure that the > software produced correct results from valid input. But making a program > work is the easy part. The hard part is making it NOT work in a secure > manner. That is, when faced with invalid input, it should not process it as > if it were valid input. That is what a true security researcher does. He/She > finds what input is accepted by a program when it shouldn't and determines > what are the consequences of that input. True QA and testing > compartmentalizes all possible input so that one can be assured that invalid > input will be safely rejected or at least sanitized. One can never assume > that the arguments to any routine are valid, If they ever come from > "outside" they need to be treated as tainted. > In a old batch mainframe environment, rejecting bad input often just > means correct the data and try over. In an online continuous transaction > processing environment (which Internet servers are), one can't often just > reject the bad input. One has to unravel all the good input that preceded it > and that is dependent on the bad input to ensure that the internal state of > your processor is still valid (the database is not corrupted, for instance). > This means that QA is immensely harder than when these systems were written. > But people are attaching these old systems to the modern Internet without > taking these differences into account. A system that kept account > information unencrypted since it was only going to travel over a closed LAN, > is not going to cut being connected to a web server that connects to the > open Internet. There is no such thing as a LAN anymore. Once you allow your > users to connect to the Internet, all the old assumptions are invalid. You > really should start over gain and redesign your applications with the new > requirements. doest your keyboard has got an enter key? regards nico -- Nico Golde nico@...lde.de public key available on: http://www.ngolde.de/gpg.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040122/618fe972/attachment.bin
Powered by blists - more mailing lists