A story of what happens when you get caught...
on
Infiltration
·
· Score: 3
A few years back, a friend and I were "infiltrating" an abandoned Nike missile site located in the upper Florida Keys. On the way out of the wooded area we had the misfortune of being stopped (at gunpoint) by a US Customs officer. There's nothing like the adrenaline rush one experiences when you come around the corner and see some guy in shorts (no badge or other identifying clothing) aiming a 9mm at you and yelling at you to get down on the ground (without identifying himself as being associated with law enforcement). Apparently the old roads in that area are used by drug traffickers to move into vehicles shipments that are dropped via plane into the ocean and we were now a suspected drug trafficker for being in that area. We spent the first hour laying face down in the middle of the road in the humid, blazing heat as the lone officer awaited backup. We spent the next two hours sitting handcuffed on the ground as the various local authorities tried to figure out who exactly held jurisdiction over the area we had trespassed in. One by one they came over the two hour period: the Sheriff's office, the Florida Marine Patrol, the Parks Department. By the end of the 3-4 hour roasting there were about eight officers from every imagineable government agency. They decided that the parks department had jurisdiction and we were charged with trespassing on park property and assigned a court date.
Prior to the court date the parks department discovered that the location we were sighted and arrested at, which was about 20 feet from the side of a state road, was not in fact "park property" (and was instead a DOT right-of-way) and the charges were dropped.
I was replying to the section of your message that stated:
==
Commercial scanners are not produced by "a person off the street". They're produced by professionals that work for companies that have a significant motive for ensuring the accuracy of their products: money.
==
I was implying that apparently this motivation was insufficient.
As for the moderation of your post as "flamebait", I certainly did not do that nor do I feel it is flamebait. A typical example of mis-moderation.
I would like to thank the asshole that modded me down and caused me to lose karma. Pointing out that an important message had been missed by the moderators isn't exactly off-topic. By moderating down people who are posting as non-anonymous you are promoting the type of anonymous-user bullshit that plagues slashdot.
==
Has there every actually been an actual and successful exploit using a buffer overrun that caused anything other than a GPF/segfault?
==
The original shockwave player buffer overflow post was made into bugtraq a few days ago. Typically, once someone demonstrates a buffer overflow in such a widely used product, someone else will post a working exploit within 30-60 days. So the answer to your question is a resounding YES.
==
This was a pretty liberal judge as it turns out, he had a laptop on his desktop the whole time. My cousin thought he saw what looked like gnome running on it but he couldn't be sure.
==
... and let me guess, Netscape was open and it looked like the judge was browsing slashdot.
=
As a person who has developed literally hundreds of smaller- to mid-size e-commerece sites, it always astounds me to find the number of people who assume that IIS is inherently insecure.
=
As a person who administers scores of NT boxes that currently services over 500 domains in both a dedicated server and shared-hosting environment, I can assure you that IIS is "inherently" insecure. By this I mean that extraordinary steps are required to provide an acceptable level of security, security is not inherent in the software by any means.
If you foolishly believe that IIS is secure, take a look at
and start from there, it's really just the tip of the iceberg. IIS has no suexec-type mechanism, so there is very little security flexibility and compartmentalization, as you can see from the content at the URL above it is even possible to execute ASP code in the SYSTEM context. Unless of course you have made manual registry changes to obscure keys. How exactly does that meet the "inherently secure" definition? It's not like it's just one issue, either. The software is plagued with poor design.
While I am on a roll here, should I touch on the issues with the FTP service, since it is part of IIS? How about the fact that users can walk all over the directory tree because the software doesn't support the equivalent of chroot jailing? How about the fact that when frontpage extensions are installed on the web site and anonymous FTP is enabled, the _vti_pvt directories become warez repositories because the "everyone" user has read and write access to that directory? Some of the largest hosting facilities in the US, such as Interland, have been waiting for an answer from MS on that one.
I had better stop now.
=
There are already Windows-based realtime DSP effects boxes that use mLAN as the routing interface, currently in *development* by a number of large music companies (I can't drop names here, I'm under very tight NDA).
=
Hey, you should let these guys know that before they code support for ultra-niche hardware configurations they should implement SMP support. Unless "number of large music companies" = digidesign; because protools is the only audio software I can think of that already supports SMP.
It's odd that you mention this, I just spoke with the developer of spamcop, Julian Haight, about this exact issue two days ago. I was irritated that spamcop sent so many complaint messages to our abuse account. However, after listening to Julian's reasoning, it is very understandable why spamcop does this. It's really simple. It sends a message for each complaint filed, same thing that happens when non-spamcop complaints are filed with an ISP. He pointed out that many ISPs will not respond to complaints until a certain number are filed, that some ISPs save all complaints, and that it probably wasn't good to just discard the complaints. To top it off, there is even an email address that will automatically close out spamcop issues, so a relatively simple procmail recipe will allow sysadmins to only receive one message (the first report) per spam incident. With that last item in mind, there are really no valid complaints that can be made about spamcop from a sysadmin standpoint.
Maybe you are seeing the wrong message? Mine starts with "the problem with nuclear power...". Also, you said you wanted to debate safety, which is the topic of my message. I am not arguing for or against them, my message primarly stated that nuclear power plants pose a much higher risk than conventional power generation plants.
With current reactor technology, nuclear byproducts and the result of a nuclear accident are far worse than any output from a fossil fuel plant. For starters, just look at the length of time the contaminants remain.
It's kind of absurd to imply that the explosion of a fossil fuel facility would even remotely compare to the explosion of a nuclear facility. Look at the current state of the chernobyl site!
Your description of the events surrounding the accident are far too summarized and are thus incorrect. All coolant was not disabled, the ECCS was disabled. All control rods were not removed. The events that caused the accident were not that few and simple. A relatively complex series of mistakes (aside from the idiocy of the experiment) caused the accident.
The close of your message reads as if everyone can just move back to that area now. This is equally absurd. Animals born in the area still have an abnormally high rate of birth defects. Certain areas are still uninhabitable. The sarcophagus is falling apart and what it contains is more lethal than what escaped during the original incident. The catastrophic failure of a fossil fuel plant would certainly not have the type of long-term effect that the Chernobyl accident had.
I am not against nuclear power, it was just odd to see these messages posted implying that there were no problems with nuclear power, as if the posters had the solutions to the major issues drawn out on a napkin stuffed in their back pocket.
The problem with nuclear power is that mundane human error or mechanical failure can have catastrophic consequences. Your statements about nuclear power's safety takes no accounting for the type of mistakes and failures that will occur in any system as complicated as a nuclear power plant. The worst thing that can happen at a coal, oil, or natural gas plant is a massive explosion. The worst thing that can happen in a nuclear plant is a massive steam explosion, the subsequent rain of radioactive debris, and a superheated critical core eminating radiation that will be both unreachable due to heat and radioactivity and will additionally remain in this unreachable superheated radioactive state for a really long time. It does not take a complex series of events to cause this to happen, instead, it takes a complex series of events to prevent this from happening and only a few relatively minor failures in either operation, equipment, or both will launch the chain of events that can result in catastrophic failure.
If you study the events that caused the TMI and Chernobyl incidents you will see how easily relatively mundane failures and mistakes can be compounded. Granted, currently utilized PWR and RBMK designs are not exactly cutting edge, but the constant failures of the US space program, although typically not catastrophic, prove to demonstrate that design, manufacturing, and operation of complex cutting-edge systems designed for high reliability are even to this day not highly reliable.
When the first sentence of the article, which concerns potential patent infringement, ends in the statement "has sued U.S.-based Prodigy Communications Corp. for copyright infringement", one can only wonder about the accuracy of the entire article. I suspect they would be suing for patent infringement, not copyright infringement.
I do not find the RBL that useful in stopping spam. It is the MAPS RSS and DUL that do the majority of the spam stoppage on our network and there is no controversy over those two services.
Perl and ASP (we will assume that you mean VBScript) can both be used in either a procedural or OOP manner (or both). So you use procedural development for simple stuff and OOP for complex projects. SQL is a database query language, I dont see it really as having relevancy to the issue. Essentially, your information is so inaccurate it makes me wonder if you have any experience with any of the four languages you mention.
=====
Their POP3 servers also appear to be affected adversely by Outlook.
=====
I have experienced a problem sending email through outlook express. I had a file that, when attached to a message in outlook, would freeze up halfway through sending. It would do this consistently.
The "bad" part was that each time I tried to send the message, another two sendmail processes were created on the mail server. I assume that outlook was not properly closing the sockets when I aborted the send because it took many hours before the sendmail processes quit even though my attempts to send the message were long past. I was able to consistently reproduce this across multiple sendmail installations, I could've filled the process table relatively easily. It was bizarre. The file was an mp3 file (I could send any other mp3 or regular file), I ended up zipping it.
This is moronic and useless. Teergrubing only hurts ISPs and doesnt affect spammers at all. In most cases, teergrubing will tie up the bastion mail servers while the user's spam is still being spooled on the inside mail server. The spammer will never know anything happened, and some hapless admin is paged at 2am to determine why mail delivery is taking so long. The best solution to spam, and the only real solution, is for people to stop responding to it. If there was a 0% response rate to spam, the problem would be self eliminating. Of course, maybe monkeys will fly out of my arse also...
Since the project seems to have nothing to do with using spare computer resources and instead seems to use bandwidth, I wonder how the project factors quality of bandwidth into the reported statistics? If you are using a distributed environment to crunch numbers, everything is great, everyone crunches their numbers, the amount of CPU being simultaneously used by other processes on the machine is irrelevant because the speed at which the results are being computed is not relevant.
However, in order to monitor QOS on web sites, a clean pipe is necessary, because the amount of time that the "calculation" takes to complete *is* the actual desired information. Now, if I am downloading gallons of pron and warez over my T1, and this client software is trying to ping yahoo.com to determine site response time, how exactly does that give a realistic representation of yahoo's availability from my part of the net? It doesn't. I do not see any way that the client software could realistically determine any preexisting bandwidth latency prior to performing its QoS tests, so it seems like the results are going to pretty much be random.
=====
Well, the best answer I could give you is it depends. What is your primary server base? Are your accounts primarily NT or Unix based accounts? The real strongpoint for many mail systems is seamless authentication, so it depends on your server base. Exchange 5.5 properly implimented is quite reliable, and so is the RTM (Release to Manufacturing) version of Exchange 2000.
=====
I think your questions are incorrect. The question I would ask is "how much mail volume are you processing" and "what percentage of that volume is intranet versus internet". The real "strongpoint" for a mail system and for any system that is going to be connected to the internet needs to be security followed closely by reliability. Speaking from the voice of someone whose job it is to administer 25 NT web servers, NT is not the pinnacle of security or reliability, and NT-based mail solutions are behind their unix-type counterparts as far as scalibility and reliability go. I would be very reluctant to put a service as critical as email on an NT machine and then expose that machine to the internet.
There are other scheduling and calendaring systems available, PHBs love "Goldmine". Use of a solution of that nature would allow the more critical mail processing to remain on a unix-type OS while allowing for scheduling capabilities from an NT solution.
Slashdot Mirror
A few years back, a friend and I were "infiltrating" an abandoned Nike missile site located in the upper Florida Keys. On the way out of the wooded area we had the misfortune of being stopped (at gunpoint) by a US Customs officer. There's nothing like the adrenaline rush one experiences when you come around the corner and see some guy in shorts (no badge or other identifying clothing) aiming a 9mm at you and yelling at you to get down on the ground (without identifying himself as being associated with law enforcement). Apparently the old roads in that area are used by drug traffickers to move into vehicles shipments that are dropped via plane into the ocean and we were now a suspected drug trafficker for being in that area. We spent the first hour laying face down in the middle of the road in the humid, blazing heat as the lone officer awaited backup. We spent the next two hours sitting handcuffed on the ground as the various local authorities tried to figure out who exactly held jurisdiction over the area we had trespassed in. One by one they came over the two hour period: the Sheriff's office, the Florida Marine Patrol, the Parks Department. By the end of the 3-4 hour roasting there were about eight officers from every imagineable government agency. They decided that the parks department had jurisdiction and we were charged with trespassing on park property and assigned a court date.
Prior to the court date the parks department discovered that the location we were sighted and arrested at, which was about 20 feet from the side of a state road, was not in fact "park property" (and was instead a DOT right-of-way) and the charges were dropped.
badtz-maru
Spamming is done by spammers. Not spaming by Spamers.
I was replying to the section of your message that stated:
==
Commercial scanners are not produced by "a person off the street". They're produced by professionals that work for companies that have a significant motive for ensuring the accuracy of their products: money.
==
I was implying that apparently this motivation was insufficient.
As for the moderation of your post as "flamebait", I certainly did not do that nor do I feel it is flamebait. A typical example of mis-moderation.
If this is the case then why did none of the software detect all 17 of the issues?
I would like to thank the asshole that modded me down and caused me to lose karma. Pointing out that an important message had been missed by the moderators isn't exactly off-topic. By moderating down people who are posting as non-anonymous you are promoting the type of anonymous-user bullshit that plagues slashdot.
==
Has there every actually been an actual and successful exploit using a buffer overrun that caused anything other than a GPF/segfault?
==
The original shockwave player buffer overflow post was made into bugtraq a few days ago. Typically, once someone demonstrates a buffer overflow in such a widely used product, someone else will post a working exploit within 30-60 days. So the answer to your question is a resounding YES.
Jeff
==
... and let me guess, Netscape was open and it looked like the judge was browsing slashdot.
This was a pretty liberal judge as it turns out, he had a laptop on his desktop the whole time. My cousin thought he saw what looked like gnome running on it but he couldn't be sure.
==
I dont understand the "IDE RAID is coming" thing, I have been using IDE RAID for 4 years using a under-$150 card, it isn't exactly new technology.
badtz-maru
Sendmail and procmail run under linux and that is what the article is about.
=
I agree that IIS is insecure, but I dont agree that it is fundamentally a bad model. IIS could be workable, but MS needs to get moving on it.
=
I agree with you.
badtz-maru
=
r aq /2000/Dec/0202.html
As a person who has developed literally hundreds of smaller- to mid-size e-commerece sites, it always astounds me to find the number of people who assume that IIS is inherently insecure.
=
As a person who administers scores of NT boxes that currently services over 500 domains in both a dedicated server and shared-hosting environment, I can assure you that IIS is "inherently" insecure. By this I mean that extraordinary steps are required to provide an acceptable level of security, security is not inherent in the software by any means.
If you foolishly believe that IIS is secure, take a look at
http://www.securityportal.com/list-archive/bugt
and start from there, it's really just the tip of the iceberg. IIS has no suexec-type mechanism, so there is very little security flexibility and compartmentalization, as you can see from the content at the URL above it is even possible to execute ASP code in the SYSTEM context. Unless of course you have made manual registry changes to obscure keys. How exactly does that meet the "inherently secure" definition? It's not like it's just one issue, either. The software is plagued with poor design.
While I am on a roll here, should I touch on the issues with the FTP service, since it is part of IIS? How about the fact that users can walk all over the directory tree because the software doesn't support the equivalent of chroot jailing? How about the fact that when frontpage extensions are installed on the web site and anonymous FTP is enabled, the _vti_pvt directories become warez repositories because the "everyone" user has read and write access to that directory? Some of the largest hosting facilities in the US, such as Interland, have been waiting for an answer from MS on that one.
I had better stop now.
badtz-maru
=
There are already Windows-based realtime DSP effects boxes that use mLAN as the routing interface, currently in *development* by a number of large music companies (I can't drop names here, I'm under very tight NDA).
=
Hey, you should let these guys know that before they code support for ultra-niche hardware configurations they should implement SMP support. Unless "number of large music companies" = digidesign; because protools is the only audio software I can think of that already supports SMP.
badtz-maru
Of course this would require Cubase to become SMP-aware on Win32, which probably is about as likely as the distributed thing.
It's odd that you mention this, I just spoke with the developer of spamcop, Julian Haight, about this exact issue two days ago. I was irritated that spamcop sent so many complaint messages to our abuse account. However, after listening to Julian's reasoning, it is very understandable why spamcop does this. It's really simple. It sends a message for each complaint filed, same thing that happens when non-spamcop complaints are filed with an ISP. He pointed out that many ISPs will not respond to complaints until a certain number are filed, that some ISPs save all complaints, and that it probably wasn't good to just discard the complaints. To top it off, there is even an email address that will automatically close out spamcop issues, so a relatively simple procmail recipe will allow sysadmins to only receive one message (the first report) per spam incident. With that last item in mind, there are really no valid complaints that can be made about spamcop from a sysadmin standpoint.
badtz-maru
Maybe you are seeing the wrong message? Mine starts with "the problem with nuclear power...". Also, you said you wanted to debate safety, which is the topic of my message. I am not arguing for or against them, my message primarly stated that nuclear power plants pose a much higher risk than conventional power generation plants.
badtz-maru
=====
If there is anyone who wants to debate the safety
of a properly designed and properly run nuclear
power plant, state your arguments
=====
My argument is in this message.
badtz-maru
With current reactor technology, nuclear byproducts and the result of a nuclear accident are far worse than any output from a fossil fuel plant. For starters, just look at the length of time the contaminants remain.
It's kind of absurd to imply that the explosion of a fossil fuel facility would even remotely compare to the explosion of a nuclear facility. Look at the current state of the chernobyl site!
Your description of the events surrounding the accident are far too summarized and are thus incorrect. All coolant was not disabled, the ECCS was disabled. All control rods were not removed. The events that caused the accident were not that few and simple. A relatively complex series of mistakes (aside from the idiocy of the experiment) caused the accident.
The close of your message reads as if everyone can just move back to that area now. This is equally absurd. Animals born in the area still have an abnormally high rate of birth defects. Certain areas are still uninhabitable. The sarcophagus is falling apart and what it contains is more lethal than what escaped during the original incident. The catastrophic failure of a fossil fuel plant would certainly not have the type of long-term effect that the Chernobyl accident had.
I am not against nuclear power, it was just odd to see these messages posted implying that there were no problems with nuclear power, as if the posters had the solutions to the major issues drawn out on a napkin stuffed in their back pocket.
badtz-maru
The problem with nuclear power is that mundane human error or mechanical failure can have catastrophic consequences. Your statements about nuclear power's safety takes no accounting for the type of mistakes and failures that will occur in any system as complicated as a nuclear power plant. The worst thing that can happen at a coal, oil, or natural gas plant is a massive explosion. The worst thing that can happen in a nuclear plant is a massive steam explosion, the subsequent rain of radioactive debris, and a superheated critical core eminating radiation that will be both unreachable due to heat and radioactivity and will additionally remain in this unreachable superheated radioactive state for a really long time. It does not take a complex series of events to cause this to happen, instead, it takes a complex series of events to prevent this from happening and only a few relatively minor failures in either operation, equipment, or both will launch the chain of events that can result in catastrophic failure.
If you study the events that caused the TMI and Chernobyl incidents you will see how easily relatively mundane failures and mistakes can be compounded. Granted, currently utilized PWR and RBMK designs are not exactly cutting edge, but the constant failures of the US space program, although typically not catastrophic, prove to demonstrate that design, manufacturing, and operation of complex cutting-edge systems designed for high reliability are even to this day not highly reliable.
off the soapbox
badtz-maru
When the first sentence of the article, which concerns potential patent infringement, ends in the statement "has sued U.S.-based Prodigy Communications Corp. for copyright infringement", one can only wonder about the accuracy of the entire article. I suspect they would be suing for patent infringement, not copyright infringement.
badtz-maru
I do not find the RBL that useful in stopping spam. It is the MAPS RSS and DUL that do the majority of the spam stoppage on our network and there is no controversy over those two services.
maru
Perl and ASP (we will assume that you mean VBScript) can both be used in either a procedural or OOP manner (or both). So you use procedural development for simple stuff and OOP for complex projects. SQL is a database query language, I dont see it really as having relevancy to the issue. Essentially, your information is so inaccurate it makes me wonder if you have any experience with any of the four languages you mention.
Maru
=====
Their POP3 servers also appear to be affected adversely by Outlook.
=====
I have experienced a problem sending email through outlook express. I had a file that, when attached to a message in outlook, would freeze up halfway through sending. It would do this consistently.
The "bad" part was that each time I tried to send the message, another two sendmail processes were created on the mail server. I assume that outlook was not properly closing the sockets when I aborted the send because it took many hours before the sendmail processes quit even though my attempts to send the message were long past. I was able to consistently reproduce this across multiple sendmail installations, I could've filled the process table relatively easily. It was bizarre. The file was an mp3 file (I could send any other mp3 or regular file), I ended up zipping it.
Maru
This is moronic and useless. Teergrubing only hurts ISPs and doesnt affect spammers at all. In most cases, teergrubing will tie up the bastion mail servers while the user's spam is still being spooled on the inside mail server. The spammer will never know anything happened, and some hapless admin is paged at 2am to determine why mail delivery is taking so long. The best solution to spam, and the only real solution, is for people to stop responding to it. If there was a 0% response rate to spam, the problem would be self eliminating. Of course, maybe monkeys will fly out of my arse also...
Maru
Since the project seems to have nothing to do with using spare computer resources and instead seems to use bandwidth, I wonder how the project factors quality of bandwidth into the reported statistics? If you are using a distributed environment to crunch numbers, everything is great, everyone crunches their numbers, the amount of CPU being simultaneously used by other processes on the machine is irrelevant because the speed at which the results are being computed is not relevant.
However, in order to monitor QOS on web sites, a clean pipe is necessary, because the amount of time that the "calculation" takes to complete *is* the actual desired information. Now, if I am downloading gallons of pron and warez over my T1, and this client software is trying to ping yahoo.com to determine site response time, how exactly does that give a realistic representation of yahoo's availability from my part of the net? It doesn't. I do not see any way that the client software could realistically determine any preexisting bandwidth latency prior to performing its QoS tests, so it seems like the results are going to pretty much be random.
Maru
=====
Well, the best answer I could give you is it depends. What is your primary server base? Are your accounts primarily NT or Unix based accounts? The real strongpoint for many mail systems is seamless authentication, so it depends on your server base. Exchange 5.5 properly implimented is quite reliable, and so is the RTM (Release to Manufacturing) version of Exchange 2000.
=====
I think your questions are incorrect. The question I would ask is "how much mail volume are you processing" and "what percentage of that volume is intranet versus internet". The real "strongpoint" for a mail system and for any system that is going to be connected to the internet needs to be security followed closely by reliability. Speaking from the voice of someone whose job it is to administer 25 NT web servers, NT is not the pinnacle of security or reliability, and NT-based mail solutions are behind their unix-type counterparts as far as scalibility and reliability go. I would be very reluctant to put a service as critical as email on an NT machine and then expose that machine to the internet.
There are other scheduling and calendaring systems available, PHBs love "Goldmine". Use of a solution of that nature would allow the more critical mail processing to remain on a unix-type OS while allowing for scheduling capabilities from an NT solution.
Maru