SoylentNews is people
SoylentNews
I've pushed an emergency fix to production to close bug #142 on the tracker. For those unaware, Slashcode portscans every user when they login or post a comment. While we knew that there was some code involved in checking for open proxies, I thought it had been disabled, and the default settings in the database all default to off. The fact of the matter though is the backend was ignoring all disable checks in the database and scanning every IP to see if they were a proxy on ports 80, 3123, 8000, and 8080.
I'm f****** seething; this is unacceptable for any site, and this behaviour isn't documented anywhere; we've been portscanning since day one and were completely unaware of it. My guess is almost everyone here was unaware of this "feature" as well. Our submitter reports slashdot did this as well. There is no notification or link in the FAQ that this is done, unless you were checking your firewall rules religiously, this would have been completely unnoticed.
I'm seething and furious at the moment. How on earth is this acceptable behaviour? I understand proxy scanning; most IRC networks do it, but they notify you that they are doing so. Furthermore, a basic web application should not be probing their end users; I'm absolutely flabbergasted that this exists, as were most of the staff when it was brought to our attention. On behalf of the site, I want to offer a formal apology for this clusterf***.
Addendum: Since writing this, I've written a follow up on why this got me so upset in my journal. I've got journal replies set to on, and will respond to anyone both here and there.Here's the revelent bit of code from Slash/DB/MySQL/MySQL.pm (yes, it lives in the DB API, no I don't know why)
Leave your comments below, I want to know how others feel about this "feature".
Update: We've confirmed that slashdot.jp and Barrapunto predate this feature being added to the codebase; according to the git log, it was added on commit 177e2213 at 2008-04-16 19:07:46 +0000.
I'm f****** seething; this is unacceptable for any site, and this behaviour isn't documented anywhere; we've been portscanning since day one and were completely unaware of it. My guess is almost everyone here was unaware of this "feature" as well. Our submitter reports slashdot did this as well. There is no notification or link in the FAQ that this is done, unless you were checking your firewall rules religiously, this would have been completely unnoticed.
I'm seething and furious at the moment. How on earth is this acceptable behaviour? I understand proxy scanning; most IRC networks do it, but they notify you that they are doing so. Furthermore, a basic web application should not be probing their end users; I'm absolutely flabbergasted that this exists, as were most of the staff when it was brought to our attention. On behalf of the site, I want to offer a formal apology for this clusterf***.
Addendum: Since writing this, I've written a follow up on why this got me so upset in my journal. I've got journal replies set to on, and will respond to anyone both here and there.Here's the revelent bit of code from Slash/DB/MySQL/MySQL.pm (yes, it lives in the DB API, no I don't know why)
sub checkForOpenProxy {
my($self, $ip) = @_;
# If we weren't passed an IP address, default to whatever
# the current IP address is.
if (!$ip && $ENV{GATEWAY_INTERFACE}) {
my $r = Apache->request;
$ip = $r->connection->remote_ip if $r;
}
# If we don't have an IP address, it can't be an open proxy.
return 0 if !$ip;
# Known secure IPs also don't count as open proxies.
my $constants = getCurrentStatic();
my $gSkin = getCurrentSkin();
my $secure_ip_regex = $constants->{admin_secure_ip_regex};
return 0 if $secure_ip_regex && $ip =~ /$secure_ip_regex/;
# If the IP address is already one we have listed, use the
# existing listing.
my $port = $self->getKnownOpenProxy($ip);
if (defined $port) {
#print STDERR scalar(localtime) . " cfop no need to check ip '$ip', port is '$port'\n";
return $port;
}
#print STDERR scalar(localtime) . " cfop ip '$ip' not known, checking\n";
# No known answer; probe the IP address and get an answer.
my $ports = $constants->{comments_portscan_ports} || '80 8080 8000 3128';
my @ports = grep /^\d+$/, split / /, $ports;
return 0 if !@ports;
my $timeout = $constants->{comments_portscan_timeout} || 5;
my $connect_timeout = int($timeout/scalar(@ports)+0.2);
my $ok_url = "$gSkin->{absolutedir}/ok.txt";
my $pua = Slash::Custom::ParUserAgent->new();
$pua->redirect(1);
$pua->max_redirect(3);
$pua->max_hosts(scalar(@ports));
$pua->max_req(scalar(@ports));
$pua->timeout($connect_timeout);
#use LWP::Debug;
#use Data::Dumper;
#LWP::Debug::level("+trace"); LWP::Debug::level("+debug");
my $start_time = Time::HiRes::time;
local $_proxy_port = undef;
sub _cfop_callback {
my($data, $response, $protocol) = @_;
#print STDERR scalar(localtime) . " _cfop_callback protocol '$protocol' port '$_proxy_port' succ '" . ($response->is_success()) . "' data '$data' content '" . ($response->is_success() ? $response->content() : "(fail)") . "'\n";
if ($response->is_success() && $data eq "ok\n") {
# We got a success, so the IP is a proxy.
# We should know the proxy's port at this
# point; if not, that's remarkable, so
# print an error.
my $orig_req = $response->request();
$_proxy_port = $orig_req->{_slash_proxytest_port};
if (!$_proxy_port) {
print STDERR scalar(localtime) . " _cfop_callback got data but no port, protocol '$protocol' port '$_proxy_port' succ '" . ($response->is_success()) . "' data '$data' content '" . $response->content() . "'\n";
}
$_proxy_port ||= 1;
# We can quit listening on any of the
# other ports that may have connected,
# returning immediately from the wait().
# So we want to return C_ENDALL. Except
# C_ENDALL doesn't seem to _work_, it
# crashes in _remove_current_connection.
# Argh. So we use C_LASTCON.
return LWP::Parallel::UserAgent::C_LASTCON;
}
#print STDERR scalar(localtime) . " _cfop_callback protocol '$protocol' succ '0'\n";
}
#print STDERR scalar(localtime) . " cfop beginning registering\n";
for my $port (@ports) {
# We switch to a new proxy every time thru.
$pua->proxy('http', "http://$ip:$port/");
my $req = HTTP::Request->new(GET => $ok_url);
$req->{_slash_proxytest_port} = $port;
#print STDERR scalar(localtime) . " cfop registering for proxy '$pua->{proxy}{http}'\n";
$pua->register($req, \&_cfop_callback);
}
#print STDERR scalar(localtime) . "pua: " . Dumper($pua);
my $elapsed = Time::HiRes::time - $start_time;
my $wait_timeout = int($timeout - $elapsed + 0.5);
$wait_timeout = 1 if $wait_timeout wait($wait_timeout);
#print STDERR scalar(localtime) . " cfop done with wait, returning " . (defined $_proxy_port ? 'undef' : "'$port'") . "\n";
$_proxy_port = 0 if !$_proxy_port;
$elapsed = Time::HiRes::time - $start_time;
# Store this value so we don't keep probing the IP.
$self->setKnownOpenProxy($ip, $_proxy_port, $elapsed);
return $_proxy_port;
} Leave your comments below, I want to know how others feel about this "feature".
Update: We've confirmed that slashdot.jp and Barrapunto predate this feature being added to the codebase; according to the git log, it was added on commit 177e2213 at 2008-04-16 19:07:46 +0000.
This discussion has been archived.
No new comments can be posted.
F%1&£@! Unbelievable: Slashcode Portscanning Disabled
|
Log In/Create an Account
| Top
| 91 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Never look up when dragons fly overhead.
(Score: 5, Insightful) by TrumpetPower! on Wednesday April 09 2014, @07:33PM
So, first, thanks for finding and fixing it, and for being so transparent about it.
My next thought is that, if that loverly little shitbomb was lurking in there all this time, who knows what else may be going on?
I know you've got intentions to do all sorts of overhaul types of things to Slashcode, but, especially in light of this discovery, are there any more immediate plans for a security audit?
b&
All but God can prove this sentence true.
(Score: 4, Informative) by NCommander on Wednesday April 09 2014, @07:39PM
Yes, this is really high up on the priorities list now. We *do* have slash apparmored but we allowed it to talk to anything via TCP/UDP (useful for debugging since staff can use an internal proxy to completely bypass varnish). We're going to look at locking it down so it can only talk to varnish and kill any fun shit like this that originates from the Apache process.
Still always moving
(Score: 2) by frojack on Wednesday April 09 2014, @07:51PM
Can you tell from whence this code came?
Is it in the original Slashcode from slashdot years ago, or something put into the public archives by some nefarious person?
What was done with the information obtained, (open ports)? Were they logged anywhere?
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by NCommander on Wednesday April 09 2014, @07:56PM
This came from slashcode itself, and was added in 2008. It's been confirmed that slashdot shows the same behavior. I put the git revision in the article itself.
Still always moving
(Score: 2, Interesting) by ticho on Thursday April 10 2014, @06:54AM
For crying out loud, just make a deal with pipedot and ditch that slashabomination already.
(Score: 2) by dmc on Wednesday April 09 2014, @07:55PM
Next thing you know after all the cybersecurity issues this past year, the ISPs (and everyone) will actually start looking at all the traffic going on on their networks and start doing something about the traffic which has no justification for existing (*cough* NSA *cough* GHCQ *cough*).
This issue seems starkly related in my mind to the reporting on heartbleed which talks about "it doesn't leave any trace". Of course a heartbleed attack leaves a trace. The attacker sends and receives packets over various networks. Those packets can be noticed if people actually take the time and effort to look.
I imagine in the coming years there is going to be a lot more looking, and perhaps even some more seething after some more finding.
(Score: 2) by Nerdfest on Wednesday April 09 2014, @08:29PM
I thought it was well known that this was there. I remember log delays when posting on SlashDot about 10 years ago that were caused by the port scan in some environments (where I worked being one of them). I thought it had been removed as I remember it being mentioned and it seemed to speed up. Sounds like these two events were not necessarily related.