| |||||||||||||
A look at the MS-SQL wormA look at the MS-SQL wormPosted Jan 30, 2003 9:21 UTC (Thu) by skellba (guest, #8043)In reply to: A look at the MS-SQL worm by JoeBuck Parent article: A look at the MS-SQL worm formal proof of correctness of programs is pratically impossible: the task is too big to be done. It would be better to not use programming languages like C or C++ which are inherently prone to buffer overflows and memory overwrites. What me really concerns is that there are so many database-servers obviously not behind a firewall: this is definitiv a problem of understanding network security and missing knowledge about Microsoft products.
(Log in to post comments)
A look at the MS-SQL worm Posted Jan 30, 2003 10:29 UTC (Thu) by libra (guest, #2515) [Link] -> "missing knowledge about Microsoft products"But who should care about that? It is not a problem of knowing Microsoft or Linux or Solaris or whatever. The problem is understanding what you do, this require knowledge about something more basic : TCP/IP, Filtering, 3-tier architecture etc... I personnaly feel as confident with Microsoft or Linux not because I know one or the other extremly well, but because I can analyse and try to understand what I do. This is a lot more difficult on Windows because everything is hidden in metabases, registry, secret entries and behind frustrating GUIs but for the basics I can still manage what I need. So the problem is not knowledge about Microsoft to my opinion, it is basic knowledge and intelligence. But of course how do you want people to devellop both when they lose their time with bugs and patches to correct them?
A look at the MS-SQL worm Posted Jan 30, 2003 11:11 UTC (Thu) by NAR (subscriber, #1313) [Link] It would be better to not use programming languages like C or C++ which are inherently prone to buffer overflows and memory overwrites.I heard once a guy, who proudly announced his 100 line long secure webserver written in perl, and asked folks to audit it. Of course, it is not that hard to audit 100 lines of code, even if it's written in perl :-) But don't forget, that the C code of the perl interpreter should be audited also, and that is not 100 lines long...
Language versus application security Posted Jan 30, 2003 12:36 UTC (Thu) by copsewood (subscriber, #199) [Link] I think the people who design and implement very high-level programming languages (e.g. Perl, Python, Java, SQL, - 'C' is too low-level) are somewhat more likely to be able to write interpreters secured against buffer overflows etc. than the people likely to be writing network-based applications which use these tools, due to the likely differences in programming knowledge and experience.Hence it is likely that an application designer needs less security knowledge to design a reasonably robust web application in Perl (which does the memory management housekeeping within the language) than in 'C' (which manages memory within the application). Not only that but the ISP hosting virtual domains is likely to want to patch insecurities discovered in the language runtimes much quicker than most of the domain owners will patch insecure web applications.
Language versus application security Posted Jan 30, 2003 18:21 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Perl doesn't have buffer overflows, but Perl-based web applications have had tons of security holes, mostly caused by not sufficiently checking user-supplied data (../../.. in paths, cross-site scripting, and the like).
Language versus application security Posted Jan 31, 2003 0:54 UTC (Fri) by copsewood (subscriber, #199) [Link] Yep. The approach of deciding what valid data should look like and excluding everything else is similar to the default-deny approach to firewall setups. This can reduce functionality slightly or slightly increases the effort of getting added functionality secure, but its probably much less hassle than trying specifically to exclude what is considered dangerous when you can only ever have limited knowledge of what might be exploitable in future.
A look at the MS-SQL worm Posted Jan 30, 2003 12:11 UTC (Thu) by philips (guest, #937) [Link] > formal proof of correctness of programs is pratically impossible:> the task is too big to be done. It would be better to not use > programming languages like C or C++ which are inherently prone to > buffer overflows and memory overwrites. Take a look at: ----- quote start ----- In other words, you have to open source at some degree your application Another language buys you nothing - implementation & design flaws is
MS-SQL worm - open source not needed for B1 rating Posted Jan 30, 2003 20:27 UTC (Thu) by wittenberg (guest, #4473) [Link] You don't need to open source to get B1 certification. Ten years ago I worked on a product that was to have been certified A1. We had to show our code to NCSC, but only under a non-disclosure agreement. So you need other people to look at the code, but you don't let everyone look at it.
|
|||||||||||||