Slashdot Mirror

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 :)

Fun! More anti-Microsoft rhetoric. Just take a look at [securityfocus.com]. Linux doesn't look as golden as the anti-Microsoft/pro-Linux crowd would have us believe.

How does shutting down your SMTP server block port 80 or access to open relays running on other ports? I think you've exagerated a bit here.

It doesn't. I am referring to Formmail, an HTML to email CGI that is installed everywhere. A lot of the spammers we kill have scripts that run against other peoples' web servers looking for unsecured formmail scripts. Since that runs on port 80, there is not much we can do to block that kind of traffic from our users who would abuse it.

Blocking outbound port 25 stops a lot of spam. But when someone runs a server without locking down formmail, there is not much we can do to prevent our users from spamming against it. As I said, we can't exactly block port 80. We can only clean up and ban access later. Hell, if our abuse department gets logs of someone who was even *trying* to run scripts against formmail, the user is banned.

Security Focus lists formmail as the 3rd highest type of attack for the 1st quarter of 2002, behind Code Red and Nimda.

Is there really some law preventing you from doing so?

As a nationwide wholesale ISP, we fall under different FCC rules than your local ISP. The FCC does not regulate intrastate communications, so most local ISPs are not covered by the FCC. Notice the FCC website clearly says interstate communications. Since we are interstate, we fall under their scope, and thus, their regulations. IANAL, so I can't tell you the exact law. I will assume when our lawyers tell us that, they are telling the truth. That's what they get paid for, and if I wanted to argue with them, I'd have been a lawyer, not a professional geek.

And while this is getting off-topic, we can't tell if it is the same phone, due to the blocking of caller-ID. And we are a wholesaler, not a retail ISP, so we never deal with the end users directly. It is our customers who do so. And yes the authorites and banks *do care*. I'll give you the benefit of the doubt and assume you completely missed the comment about how we are routinely answering subpeonas for logs from federal and state authorities? And how they usually end at dead ends?

As for going after the guy with guns, the FBI does that for us, and we are not a "small business." Quite a few of our customers are not "small businesses" either.

Now maybe you have a small glimpse of how identity theft hurts businesses as much as it does consumers. And leads to more SPAM. See how it all ties together?

How does shutting down your SMTP server block port 80 or access to open relays running on other ports? I think you've exagerated a bit here.

It doesn't. I am referring to Formmail, an HTML to email CGI that is installed everywhere. A lot of the spammers we kill have scripts that run against other peoples' web servers looking for unsecured formmail scripts. Since that runs on port 80, there is not much we can do to block that kind of traffic from our users who would abuse it.

Blocking outbound port 25 stops a lot of spam. But when someone runs a server without locking down formmail, there is not much we can do to prevent our users from spamming against it. As I said, we can't exactly block port 80. We can only clean up and ban access later. Hell, if our abuse department gets logs of someone who was even *trying* to run scripts against formmail, the user is banned.

Security Focus lists formmail as the 3rd highest type of attack for the 1st quarter of 2002, behind Code Red and Nimda.

Is there really some law preventing you from doing so?

As a nationwide wholesale ISP, we fall under different FCC rules than your local ISP. The FCC does not regulate intrastate communications, so most local ISPs are not covered by the FCC. Notice the FCC website clearly says interstate communications. Since we are interstate, we fall under their scope, and thus, their regulations. IANAL, so I can't tell you the exact law. I will assume when our lawyers tell us that, they are telling the truth. That's what they get paid for, and if I wanted to argue with them, I'd have been a lawyer, not a professional geek.

And while this is getting off-topic, we can't tell if it is the same phone, due to the blocking of caller-ID. And we are a wholesaler, not a retail ISP, so we never deal with the end users directly. It is our customers who do so. And yes the authorites and banks *do care*. I'll give you the benefit of the doubt and assume you completely missed the comment about how we are routinely answering subpeonas for logs from federal and state authorities? And how they usually end at dead ends?

As for going after the guy with guns, the FBI does that for us, and we are not a "small business." Quite a few of our customers are not "small businesses" either.

Now maybe you have a small glimpse of how identity theft hurts businesses as much as it does consumers. And leads to more SPAM. See how it all ties together?

Give Microsoft a break. Open source software has its own fair share of exploits and worms that take advantage of unpatched boxes. I subscribe to all of the securityfocus mailing lists and I can tell you that I see a lot more *nix than MS activity.

I feel sorry for those that let their hatred of a company clout their perception on information security.

-Lucas

Interesting. Trillian already has both encrypted IMs and logging. AOL is just following their lead.

The author went on to have an interesting converstaion with Micahel Jennings, author of Eterm on Bugtraq here.

Here's a sample of Mr. Mullen's "unbiased" approach to Microsoft security:

http://www.securityfocus.com/columnists/127

Windows XP Kills Dog, Steals Toaster: Media Gone Mad

Sigh. Probably true. But give a spammer or telemarketer or other sleazeball a tiny crack and they'll stretch it to allow everything.

For instance, the "Do Not Call" list, according to this would have exemptions for a number of groups. And there seems to be a blanket exemption for charities. Just this hole raises lots of potential - the telemarketers will pay the charity some amount per call to call on their behalf -- and then toss in their sales pitch.

Just Say EGBG!

This is now built into OpenBSD (see the spamd(8) man page).

As long as you trust your local users then you may not need to upgrade as you say ... however you should be aware that a potential security issue was fixed with 10.2.4

Blaming security vulnerabilities on a lack of OO principles is misguided and wrong.

Java still has occasional vulnerabilities. Java was designed with a very robust security model from the very beginning, however vulnerabilities still pop up on occasion. Albeit not very often, but they exist. J2EE is every bit as vulnerable to JVM exploits as any other Java application. Ultimately, it's the implementor who is responsible for security.

I can't speak to the internals PHP, it may be spaghetti code, but simply sprinkling magic OOP pixie dust will not remove any and all security issues. You can write an insecure program, regardless of design or methodology, if you don't know what you're doing.

PHP's remote file inclusion and execution -- this is a huge mis-feature from a security standpoint. Whether PHP is written in C++, assembler, Java, or Lisp; whether that feature is done with OOP and design patterns, that feature is dangerous regardless of implementation!

Look at OpenBSD. It's definitely not OO, however very robust, and historically, very secure. The programmers know what they're doing.

Ultimately, the programming team's collective experience, intelligence, and paranoia determines how secure any application is.

The undocumented VMWare I/O port communication mechanism can also be (and is) used to determine whether an application is running under VMWare. The relatively simple code to implement this was posted to the Honeypots security list.

More information at Securityfocus. This is the remote exploit which seems to be a UDP amplifier.

If all ISPs actively put in anti-spoofing filters on all their routers then this type of denial of service attack could be greatly reduced as blackhats would only be able to spoof IPs & UDP services to their own segments.

But no, most ISPs probably take a router out of the box, type a few commands and take it into production.

SecurityFocus also has an interesting write-up;

"The new law against "Unlawful use of encryption" would establish prison terms for anyone who "knowingly and willfully uses encryption technology to conceal any incriminating communication".

Inter-jurisdictional searches would become allowed in case of "suspected financing of terrorist organizations, attacks on critical infrastructure, or computer crime."

The Center for Public Integrity has intercepted a sequel to the Patriot Act that is being called the "Domestic Security Enhancement Act of 2003". Here are a few mirrors to the document... (we will need more): one, two, and three. A notable part of the prospective legislation is that a new federal felony is created for willfully using encryption during the comission of a felony and that a judge in a different part of the country can issue a search warrant for another part of the country for terrorism or "computer crime". Why should you care if this isn't even close to law yet? 1) It's written by John Ashcroft and 2) The Bush administration is great at getting these things passed during emergencies (wasn't the homeland color just kicked up a notch?)

I know many Sun users who liked CDE because it was stable as a rock.

Oh yeah? Rocks come to my mind when I think of CDE, but for different reasons. For example, I liked it because of all of the gaping security holes in tooltalk that take Sun forever to patch whenever they crop up.

Now, can we compare this with a timeline of security flaws in linux and packages frequently installed on linux like mysql, bind, apache, etc?

Yes, but it is more difficult. A good place to start would be the SecurityFocus Vulnerabilities archive. Part of the difficulty is that vulnerabilities are often reported multiple times due to the various vendors, etc. etc.

Without going into a detailed analysis, Bind has the worst history if you go far back, but its frequency is a lot better now. At its worst, it was at roughly IIS levels of hole frequency and seriousness. Apache and Mysql have both low frequency of holes, and Apache tends to have more non-fatal holes than serious ones (i.e., access to files rather than remote root exploitation).

Another interesting comparison would be the resources and man hours put into, say, IIS versus Apache or MS-SQL versus MySQL. Without hard information, I think its safe to assume that the Microsoft products have had a lot more development done on them. While in a perfect world this would improve their security, I think the practical effect is to decrease their security due to code and feature bloat - "Trustworthy Computing" notwithstanding.

There are several reasons why Linux does not have non-executable stacks yet...

One of them is that gcc and the kernel use trampolines. From the gcc docs:

A "trampoline" is a small piece of code that is created at run time when the address of a nested function is taken. It normally resides on the stack, in the stack frame of the containing function.

AFAIK, linux uses trampolines at least in these places:

• Gcc uses them for nested functions (not very common though, but glibc has quite a few of those).
• The linux kernel uses (used?) trampolines for signal delivery.

Both problems can be addressed (the openwall patches take care of the kernel trampolines), but it's not as easy as turning off the PROT_EXEC bits in the stack.

Also, a non-exec stack is not a silver bullet: it only makes exploiting buffer overflows somewhat harder. Check out this article from Solar Designer (the OpenWall patch author).

On top of the above:

• Multithreaded programs have more than one stack, and they're not necessarily contiguous.
• As Theo's mail says, the i386 arch (which is still the most common linux arch, despite its suckiness) has a very limited way of implementing PROT_READ && ! PROT_EXEC pages:

  The i386 is not capable of doing per-page execute permission. At most it is only capable of drawing a line through the address space, by limiting the code segment length (using the code segment register). So we can say, "from 0 to this point is executable" and "from that point on to the end of userland is not executable".

You may now understand why Linus has so far judged that a non-executable stack was more trouble than it was worth.

The advisory is also available here

Do English-speaking people receive spam in foreign languages?

I have an email address that is used exclusively for the Bugtraq mailing list over at securityfocus, and funnily enough, out of about 30 spams a day it gets, 50% are from some 163.com company based in China, and the other half are from Nigeria (the whole "please help us get millions of dollars out of the country" scam).

I was always kind of curious as to the response the Nigerian guys got from a security-based mail-list.

"waiting on the full service pack" is not an acceptable stance.

as an admin of one or more machines, the ownus is on the admin to identify and correct the security holes that pose a threat to their machines. not every fix needs to be installed, only the ones that clearly represent a danger to the systems being cared for.

there are places, such as the bugtraq list where major security bullitins are published. simply subscribing to this list can provide the information necessary to identify the vulnerabilities that do pose a danger.

also, the *nix community has as many or more fixes released for their software packages. they also do not have "service packs" and "cumulative patches" that are so conviently bundled together.

all that is required is some critial thinking to asses which patches should be put into production and which should not. and that is the solution.

See here. It's still the best description I've seen of the "problem", but the AC really should have credited the source.

Umm no... this happens to be an MS exploit.

In particular, it affects XMLHTTP.
See here and here

Umm no... this happens to be an MS exploit.

In particular, it affects XMLHTTP.
See here and here

As been discussed on BugTraq the latest days, this is not a 'general' vunerablility, rather a bug in Microsoft's XMLHTTP component (nomatter what the whitepaper says).

References: RE: TRACE used to increase the dangerous of XSS.
Original posting to Bugtraq

As been discussed on BugTraq the latest days, this is not a 'general' vunerablility, rather a bug in Microsoft's XMLHTTP component (nomatter what the whitepaper says).

References: RE: TRACE used to increase the dangerous of XSS.
Original posting to Bugtraq

Well. That was kind of silly. I see you borrowed the text from this posting on bugtraq to whore a little karma. That's fine, but shouldn't you have been logged in?

This story is utter alarmist crap. There is nothing wrong with TRACE, and the internet is not falling apart. It's just another IE cross-site scripting vulnerability. Here's a few choice links from the discussion on bugtraq:

http://online.securityfocus.com/archive/1/307778/2 003-01-22/2003-01-28/0
http://online.securityfocus.com/archive/1/308165/2 003-01-22/2003-01-28/0

This story is utter alarmist crap. There is nothing wrong with TRACE, and the internet is not falling apart. It's just another IE cross-site scripting vulnerability. Here's a few choice links from the discussion on bugtraq:

http://online.securityfocus.com/archive/1/307778/2 003-01-22/2003-01-28/0
http://online.securityfocus.com/archive/1/308165/2 003-01-22/2003-01-28/0

There was a short article on SecurityFocus a few weeks ago... US lawmakers are requesting input from the community regarding "hacker" sentencing. Hopefully the deadline for submissions hasn't passed yet:

online.securityfocus.com/news/2028

Guidelines here:

www.ussc.gov/FEDREG/fedr1202.htm

Indeed that's possible - I even remember the last local root hole via the sperl binary.

Even if there are no buffer overflows possible it's not proof that the software is secure; lots of things need to be checked, PATHs, permissions on files, race conditions, symlink attacks, etc.

Thats why, as you say, proper programming is the way to security. A good developer should always test return codes, never use unbounded copies, etc.

This approach and idea is actually very old, and it has already been done (although not through Gamespy).

I wrote a program for Quake 1 that flooded a server with false connections and disconnected legitimate users (http://online.securityfocus.com/bid/3051), and a friend changed 1 line of code to make my exploit do a "smurf" attack on a client (http://online.securityfocus.com/bid/3060).

This approach and idea is actually very old, and it has already been done (although not through Gamespy).

I wrote a program for Quake 1 that flooded a server with false connections and disconnected legitimate users (http://online.securityfocus.com/bid/3051), and a friend changed 1 line of code to make my exploit do a "smurf" attack on a client (http://online.securityfocus.com/bid/3060).

Crap. This means that we'll be dealing with displays that have completely integrated copy-protection mechanisms.

Even if current efforts such as Intel's HDCP are flawed, future versions of these technologies may not be amenable to cryptographic attacks, and hardware based attacks will be extremely difficult if the circuitry is embedded in the screen itself.

This falls perfectly in line with the Broadcast Protection Discussion Group's desire to mandate implementation of a broadcast flag that all devices must honor.

Actually, Gobbles Security are one of the most active, and largest, exploit groups hanging around the "Security" field at the moment. They have a knack for Pissing off Theo DeRaadt.

You can see the posting to bugtraq from them on the SecurityFocus website.

hesiod says: Is he saying that "Gobbles" runs Bugtraq.org? Am I missing something here, or is he full of shit?

1. Gobbles are not stupid, they've come up with many innovative exploits, and are without a doubt very talented hackers. You may remember them from such classics as the linuxslapper worm (based on their apache-scalper code), or the nifty ettercap remote-root-via-irc exploit.
2. Obviously, the RIAA didn't hire them to "hack back". If the RIAA hired people to hack, they wouldn't talk about it on a fucking mailing list. (Furthermore, the bill that hinted at such "hack backs" wasn't ever passed.)
3. Gobbles is prone to making hilarious outlandish claims. Clearly, this is a simple mpg123 exploit preceeded with a very funny joke to make the RIAA look bad.
4. Yes, gobbles runs "bugtraq.org". That has nothing to do with the securityfocus mailinglist called bugtraq, however. It's just a domain name.

mpg123 has a vuln.
Gobbles are some funny guys.
The p2p networks are not 0wned.
(And, oh yeah, both the register and slashdot got trolled again. But thats not news anymore than "it's raining in seattle".)

I'm reading this book now. Surprisingly, it isn't so much about technology and security. Instead, it is more about understanding humans. Despite the sterotype that geeks have for being socially incompetent, to be a truly good hacker using social engineering, you have to be good socially. Maybe not great, but pretty good. And, you need to know the right language and the right people to communicate with. Mitnik does a great job with this stuff and I am really enjoying the book. (However, I'm not so sure his tactics will work as well as they did a few years ago.)

Here are some pretty good resources for learning more about social engineering:

Social Engineering: What is it, why is so little said about it and what can be done?

Social Engineering Fundamentals, Part I: Hacker Tactics

Social Engineering: The Human Side Of Hacking

Apparently the "hydra" uses exploits/overflows on a number of popular media players - including xmms, which is a Linux mp3 player and WinAMP, which is a Windows mp3 player. Therefore that would suggest it can infect multiple operating systems.

More details including the original post can be found here.

I still doubt the possible risk/effectiveness - or even that its true though.

This is the original posting.

Reading the posting, it seems unlikely.

This article may have more info that the one linked in the article.

The actual exploit was posted on buqtraaq yesterday. You can find it here. That link has the original post from the group explaining what the exploit is, how the RIAA is supposedly involved, and it has the exploit as an attachment. Check it out and decide for yourself if it's a hoax.

According to Bugtraq everyone useing P2P apps is already 0wned by the RIAA. The MPAA should ask the RIAA to just shut things down at the source.

The Amnesty "illegally imprisoned" link reguards a pare-military group as common burgulars, the Rense.com link invents another class. Both have been addressed by the US courts and neither is addressed in Kevin Poulsen's article.

All that aside, hell no a non-violent criminal should not be locked up. Some other punishment is much more appropriate, like restitution of *real* losses (no making the defendant buy a new security team) and community service, etc.

Jail *should* be for the people that are a physical threat to society, not a theoretical or financial one.

Before the thread runs off the topic, see my website for my position on the death penalty before assigning one to me.

He thinks that you should have the right to "hack-back" so you can protect your network better.

Pesonally, i don't like this type of aproach, but it should be an interesting debate where all the security comunity should be envolved.

On a side note, did anyone else notice that the government "Homeland Security" proposal for Internet monitoring is not to be done by any governmental agency, but rather outsourced to the private sector? Think that this might be a way to salvage UUNET from the Worldcom junkpile, as well as keep the public Internet as we know it up and running?

I'm pretty sure that "mmhs@hushmail.com" is the same person as the infamous "gobbles@hushmail.com", or at least an adoring fan. The day wasn't a total loss, though; it's not every day that a font file causes Windows to restart

ERRATA:

--- begin cut & paste ---

To: BugTraq
Subject: Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
Date: Jan 6 2003 8:05PM
Author: Global InterSec Research
Message-ID:
In-Reply-To:

As some may have gathered, the advisory recently posted by mmhs@hushmail.com
was indeed a fake, intended to highlight several unclear statements made in GIS2002062801.

The advisory in question is currently being updated with more detailed information and will
be
re-posted at: http://www.globalintersec.com/adv/openssh-20020628 01.txt as soon as it becomes

available.

Note that the kbd-init flaw described in GIS2002062801 was proven to be exploitable in our lab
although not all evidence to demonstrate this was provided in the original advisory. A mistake
was made in the original advisory draft, where chunk content data was shown, rather than the
entire corrupted malloc chunk. This will be amended in the revision.

Also note that to our knowledge there are currently no known, exploitable flaws in OpenSSH 3.5p1,

due to its use of PAM as suggested by mmhs@hushmail.com. It is almost certain that the posted
bogus advisory was also intended to cause alarm amongst communities using OpenSSH, through
miss-information.

Global InterSec LLC.

--- end cut & paste ---

The original advisory I was talking about can be found here.

Sorry for misguiding you, humble slashdot readers.

I don't think that integrating more functionality into the back button is a good idea. A history is fine, at least you might expect what to get this way, even though there is an occasional small hickup.

I guess I'll just be considered as against progress :)