RE: [SC-L] Origins of Security Problems
[EMAIL PROTECTED] <> wrote on Saturday, June 19, 2004 4:49 AM: > There is nothing to _prevent_ an untrained administrator from granting > that privilege to all users (I have seen worse), but there is > a damping > effect provided by the fact that behavior _defaults_ to constraining > those users. I think you missed my point completely. A little over ten years ago, the same "damping effect" was provided in TCP/IP as you say is present for DECNet. That is the sum total of my point. The only difference is popularity. As with so many other security comparisons, the technology has very little difference, it is merely the quality of system administrators that sets the systems apart. There are complaints over the monoculture of Microsoft, but if the users and administrators of existing unsecured Microsoft systems were to jump to other operating systems, they would a) choose the easiest, most open systems, and b) leave them just as unsecured as they were before. That's not to say that some operating systems don't have technological boundaries that make it easier to remain secured. But it is to say that _unless_ those technological boundaries exist, moving an admin or a user from one operating system to another will not improve their security situation in a meaningful manner. There is something to be said for using the less popular platforms, of course - viruses and worms tend to be written for maximum damage, to infect maximum numbers of systems, and can only achieve that by attacking the most popular platforms. For all that it is bug-ridden and full of security holes, a Windows for Workgroups 3.1x system put on the Internet today would probably remain unhacked for months or even years. Alun.
RE: [SC-L] Origins of Security Problems
[EMAIL PROTECTED] <> wrote on Thursday, June 17, 2004 10:59 AM: > At 9:52 AM -0700 6/17/04, Blue Boar wrote: >> Hm? You mean they had to have privs on VMS to allocate a > listening port? > What > does that matter? DECNet doesn't only run on VMS. > > But the vast majority of current DECnet usage is on VMS. And ten years ago, the vast majority of TCP/IP usage was on Unix, where you could "rely" on a source port under 1024 meaning that the connection had been sanctioned by an educated administrator who cared about keeping the Internet comfy cosy and safe. If you go back that far, you'll probably find some posts from me complaining that even then, not all Unix systems were administered by professionals, and that the recent arrival of Winsock on the stage meant that such an unreliable assumption was not even remotely going to remain true. If there is not sufficient security in the protocol, and DECnet may have enough security, there is certainly not sufficient security in assuming that your fellow network citizens are clever and kind. Alun.
RE: [SC-L] opinion, ACM Queue: Buffer Overrun Madness
[EMAIL PROTECTED] <> wrote on Wednesday, June 09, 2004 7:58 AM: > Although I am in favor of languages that help prevent such nasties as > input buffer overruns, this is an excellent point. A sloppy > programmer will write sloppy code. Reminds me of an old saying that I > heard years > ago while studying mechanical engineering: a determined > programmer can > write a FORTRAN program in ANY language. :-) (Well, notwithstanding > FORTRAN's built-in ability of handling complex numbers, but I > digress...) Going back over some of my old FORTRAN code, I find that I was writing object-oriented code in FORTRAN. Going over other people's C++ code, I can see that they're trying to make it work like FORTRAN, or QuickBASIC, or something like that. I did some work recently on .NET Security, trying to come up with some examples that would demonstrate how you'd screw it up in code. It's certainly difficult to come up with bad examples that aren't needlessly bone-headed, but when you look at other people's code, you realise that an awful lot of programmers are bone-headed. Buffer overflows can happen in any language, no matter what those languages do to prevent them. Okay, that's a bold statement. I'd better back it up. If you have a string-handling library of any kind, someone's going to come up with a program design that builds a twenty character string for a person's name, putting first name in the first ten characters, and last name in the last ten characters. Eric Smith changes his first name to Navratilova, and he's suddenly listed by the program as "Navratilovamith amith" - buffer overflow. Sure, it doesn't overflow into the stack, but it overflows into important data. And if you want to go further into insanity, you can manufacture a case where character 11 being lower case causes unwanted code to be executed (no default condition in a 'case' statement, no good error handling, etc). > IMHO, the bottom line is that there's no excuse for sloppiness and a > strong language can only do so much to prevent the programmer from > his/her own sloppiness. The first defence against unsecure coding is to hire and educate your developers in such a way as to exclude the unsecure coding practices. It's not the only defence - but it's the first you're going to need, because if you don't have that, you've got programmers who will flout security prevention measures _because_ they don't understand how to do it properly, or why they're being strong-armed in a particular direction. And on the topic of hiring better programmers, I'm now in my third week as [EMAIL PROTECTED] [But my personal address remains this one] Alun.
RE: [SC-L] Missing the point?
[EMAIL PROTECTED] wrote: > Michael A. Davis wrote: >> Isn't she missing the point? It is not the source code that is the >> problem -- it is the developer. > > Well ofcause you can improve the quality of your code by > educating your developers, but you cannot avoid doing code review. > Developers are lazy and they will commit errors. More to the point, they are human, and even developers that are not lazy will occasionally make mistakes. Simply finding a committed programmer who understands security will not produce a secure product. Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
RE: [SC-L] virtual server - security
[EMAIL PROTECTED] <> wrote on Wednesday, March 31, 2004 11:35 AM: > Sniffing on the LAN isn't my main concern, it's the > concentration points > inbetween A and B. Good idea on the SSL wrapper on Telnet, > although the > original poster said they doesn't want to offer shell access. I'm > not quite sure the security community's concensus would agree that FTP > is better than > SCP/SFTP. I certainly don't, but I've already made that > point. So that > leaves us with flaws in implementation *and* plaintext > usernames/passwords. That doesn't give me warm fuzzies. Could I interrupt this rather unenlightening exchange for just a moment to point out that you can have your cake _and_ secure it? There's a good couple of dozen implementations of the draft standard for FTP over SSL / TLS listed at http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html, not to mention any of a number of other FTP schemes that avoid passing usernames and passwords around in plaintext (S/Key, SASL, etc). You can have the comfort of FTP, the protocol you've come to love, at the same time as using a secure communications protocol that has become trusted by millions (although, with the number of "didn't read the instructions" mistakes made by some of the implementations, goodness only knows why). Okay, if I go on with this much longer, it'll turn into an advert, so I'll leave it at that. Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
RE: [SC-L] Re: Java sandboxing not used much
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Cheswick > Sent: Thursday, March 11, 2004 2:04 PM > > User client-level applications should come with recommended > sandbox.conf > files that will contain them appropriately. There's already > a shortage > of systems and network security people, and this stuff should be as > easy as possible. Ah, but that has its own problem, as everyone relies on the sample files, and certain settings are known to be the same - like having everyone's Windows system installed at "C:\WINDOWS", using sample configuration files unchanged is often as much a source of security problems as it is a means of reducing confusion. Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
RE: [SC-L] Opinion re an interesting article on Linux security in Linux Journal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michal Zalewski > Sent: Tuesday, March 09, 2004 1:16 PM > > Uhh, with some new worms, you not only can't execute the > rogue directly by > just clicking on an attachment, but you need to enter a > password to get > access to it... you just need a userbase clueless enough to > carry out even > a fairly complicated action out of curiosity, and some social > engineering. As ever, the chief flaw that is exploited by the most successful (in terms of wide spread) viruses is that of human naivete / stupidity. I reckon you'd get a fairly good spread of virus even if you asked people to type the virus code into "debug" (a tool which, among other things, allows you to directly enter hex codes). The only thing that might slow such a virus down is that many of the people typing it in would get a digit or two wrong. I've long maintained that Unix, Linux et al are not protected so much by technical superiority as by a lack of users - particularly a lack of technically uninformed users. In some cases, too, the protection is that there are less dumb developers. To truly bring Linux down, what's needed is a "Visual Basic 1.0" for Linux :-) Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer. [Ed. Let's please keep this to a discussion of design features and NOT a mudslinging contest (which no one can possibly win). Thanks. KRvW]
RE: [SC-L] Any software security news from the RSA conference?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ljknews > Sent: Friday, February 27, 2004 9:51 AM > > You must be thinking of a different Bill Gates than the one familiar > to me. I am thinking of the one who announced a few years ago that > Microsoft would stop other activities for a month and fix > their security. I wonder if this is the same Bill Gates who then doubled that time off new development (note - he doesn't talk about security as a finished job), and mandates the reading of the book "Writing Secure Code", amongst other things. But Bill isn't the only person at Microsoft, and it's really important that a large number of people at Microsoft "get it". Bill's job, when he turns up to these things, is essentially to say whatever Microsoft's game plan is, currently, not to impress us that he has found religion. What's key is the number of other people within Microsoft that "get security". As a Security MVP, I get to spend time with some of these people, and they really do seem to have a clue - I should know, I fill their inboxes with whatever my latest pontifications on security are, and I read the responses I get back very carefully. Microsoft has a lot of code to contend with, and much of it is old - so a lot of it has had to be scrubbed clean of imperfections, and some has had to be re-written. And yet, they're actually _doing_ it. How many people are howling about the decision to remove the non-RFC http format that's used by so many scammers and spammers? How many people are going to howl that enabling the firewall by default in SP2 makes life "harder" for them? There are some very tough decisions being made in the right direction here, I think. Alun. -- Texas Imperial Software | Find us at http://www.wftpd.com or email 1602 Harvest Moon Place | [EMAIL PROTECTED] Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers. Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.
