Secure hubs - fail to protect against 0.401
Moderator: Moderators
Secure hubs - fail to protect against 0.401
Ok, situation. Some hubs have a security layer called leechblocker, basically it means that unless you are a registered user of the hub in question you can't download (or if the option exisits, search either). I use this in my own hub.
Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to get a registered users filelist and that registered user then get's the UnRegistered users list (as for file share validation or just to look) that now the UnRegistered user suddenly has access to the registered users file list AND can download.
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.
Fox
Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to get a registered users filelist and that registered user then get's the UnRegistered users list (as for file share validation or just to look) that now the UnRegistered user suddenly has access to the registered users file list AND can download.
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.
Fox
-
- Posts: 506
- Joined: 2003-01-03 07:33
Missed point
The leechblocker script is fine for 99% of everything else, it's only version 0.401 that's the issue, so something has changed enough in the DC++ to make the script fail (lua script BTW)
And think about this a moment before you so idiotically dismiss the idea. One of the biggest issues in the P2P world currently is the constant harrassment or threat to users from legal agencies. By using a dedicated protection system against searches/downloads no agencies will randomly come in and get a file list from my users and use it against them. A safe place to transfer files is rare and that's what I try to provide. By requiring registration and detail share checking before registration we consider ourselves reasonably secure, until this new issue came up.
Since my concern is the protection of the users overall I hardly think that is a "singularly fucking stupid" idea. Unless of course, you are a basic leecher in which case it makes sense you would think it was stupid, after all, you're the kind of person we wouldn't want in the hub in the first place.
And think about this a moment before you so idiotically dismiss the idea. One of the biggest issues in the P2P world currently is the constant harrassment or threat to users from legal agencies. By using a dedicated protection system against searches/downloads no agencies will randomly come in and get a file list from my users and use it against them. A safe place to transfer files is rare and that's what I try to provide. By requiring registration and detail share checking before registration we consider ourselves reasonably secure, until this new issue came up.
Since my concern is the protection of the users overall I hardly think that is a "singularly fucking stupid" idea. Unless of course, you are a basic leecher in which case it makes sense you would think it was stupid, after all, you're the kind of person we wouldn't want in the hub in the first place.
In theory, yes..
In practice, I can't figure out where DC++ changed that made the scrpt fail in such a strange way. Technically the script should still work, obviously it isn't.
However, I feel anything that adds a compromise to user security needs to be considered from all factors.
This doesn't mean I'm not looking at ways to alter the script, been my full-time project for the last 2 weeks! What good is security that isn't effective with the newest releases after all?
Which is why I came here, apparently user security isn't an issue among the people that need it most. Their loss I suppose.
Fox
However, I feel anything that adds a compromise to user security needs to be considered from all factors.
This doesn't mean I'm not looking at ways to alter the script, been my full-time project for the last 2 weeks! What good is security that isn't effective with the newest releases after all?
Which is why I came here, apparently user security isn't an issue among the people that need it most. Their loss I suppose.
Fox
Protocol is protocol, some things you can influence through the hub, some things you can't. It should be pretty obvious by reading a protocol guide what things you can do. I doubt DC++ has made any big changes to the protocol from version to version.. well, unless you count the ADC changes, but those don't really apply here...
-
- Posts: 506
- Joined: 2003-01-03 07:33
No. Hubsofts has no information about what happens on the client<-->client side. They will never have any control of it. They have no control of what you download. And will never have. Its one of the key-points in the DC-architecture. Our friends script is broken and always been broken.Twink wrote:so I'm guessing his script is blocking filelists by watching for mylist.bz2 transfers when it should also look for the mylist.xml ones?
You have to learn about how the client-client protocol works, particulary the $Direction part.Foxp wrote:Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to get a registered users filelist and that registered user then get's the UnRegistered users list (as for file share validation or just to look) that now the UnRegistered user suddenly has access to the registered users file list AND can download.
The point is that your hub have never ever been secure, you have only assumed it has been. The scripts logic is not consisten with what you want it todo.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Secure hubs - fail to protect against 0.401
We us this same scheme in the DCDev Public hub. Due to the way the client to client protocol works (the fact that it can be either an upload or a download, based on the $Direction command), this isn't foolproof.Foxp wrote:apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to
It's not affected one bit by 0.401 - you'll see the same behavior back to the earliest clients you can run.
Please, if you're accusing someone of having a bug, make damn sure that it is their problem beforehand.
bug?!
I never accused anyone of having a bug!!! That's an assumption on your part. For the sake of continuity I'll post the relevant script so at least you'll have that. However, no where did I say there was a bug anyplace, just there was a change in configuration and I'm trying to place where so security can be adapted to fit.
You all have to quit jumping to conclusions (yes, I do it too sometimes).
here's the code in question:
You all have to quit jumping to conclusions (yes, I do it too sometimes).
here's the code in question:
Code: Select all
smDebugging = "0" -- Default is "0" (silent mode). "1" sends msgs to OPs
smBlockSearches = "1" -- Default is "0" (do not block searches)
smBlockSearchExceptions = { "scores", "sheet music" }
MsgToAliens = "\t\t\t*** WARNING ***\r\n\t"..
"YOU ARE UNABLE TO DOWNLOAD OR SEARCH IN THIS HUB\r\n\t"..
"Only registered users can download.\r\n\t"..
"You still can chat...\r\n\t"..
"...but the hub won't let you download or search until you register.\r\n"..
"\tIn order to become a registered member:\r\n\t"..
"1) Read !rules for share requirements\r\n\t"..
"2) only then, ask an OP for a password.\r\n\t"..
"We hope you will join us."
LetLeechCommand = "!letleech"
smBot = frmHub:GetHubBotName() -- This line gets bot name from PtokaX hubsoftware;
-- therefore, your Hub Bot should be enabled.
ToBlock = { "^$ConnectToMe%s(%S+)", "^$RevConnectToMe%s(%S+)", "^$Search%s+(%S+)"}
LetLeech = {}
--// This function is called when hub or script starts
function Main()
frmHub:EnableFullData(1)
frmHub:UnregBot(smBot)
frmHub:RegBot(smBot)
--// If thus configured, remove search from blocking table:
if smBlockSearches == "0" then
for i,v in ToBlock do
if v == "^$Search%s+(%S+)" then ToBlock[i] = nil end
end
end
end
--// This function is fired when a new user (non-OP) finishes login
function NewUserConnected(user)
if user.iProfile == -1 then
user:SendPM(smBot,"\r\n"..MsgToAliens)
end
end
--// This function is fired when new data arrives
function DataArrival (user, data)
--// See if data is the !letleech command:
if strsub(data, 1, 1) == "<" then
local line=strsub(data,1,strlen(data)-1) -- remove last char
local s,e,cmd = strfind(line, "%b<>%s+(%S+)")
local s,e,arg = strfind(line, "%b<>%s+%S+%s+(%S+)")
if strlower(cmd)==strlower(LetLeechCommand) then
if user.iProfile ~= 0 and user.iProfile ~= 1 then
SendToAll(smBot, "...but you are not an OP!")
return nil
end
who = GetItemByName(arg)
if not who then
SendToOps(smBot, arg.." is not online.")
return 1
end
if who.iProfile ~= -1 then
SendToOps(smBot, arg.." is registered and does not need a leech license.")
return 1
end
LetLeech[arg] = 1
SendToOps(smBot,arg.." has been granted a special leech license.")
who:SendData(smBot,arg..", you are now authorized to download for this session.")
return 1
end
end
--// See if data should be blocked:
for _,blockstring in ToBlock do
local _, _, who = strfind(data, blockstring)
if who then return smBlock(user,data,who) end
end
end
function smBlock(user,data,who)
local report
local profnam = GetProfileName(user.iProfile)
if profnam then
profnam = strlower(profnam)
else
profnam = "alien"
end
--// Activity by Masters, OPs, VIPs and REGs are just reported to OPs:
--// Also, searches pass if they are in the exception list:
--// Data also passes if user is in LetLeech list:
if (user.iProfile ~= -1) or smMatchException(data)
or IsInLeechList(user) then
report = "\t"..user.sName.." ("..profnam..") sends:\r\n\t"..data
smDebugToOPs(report)
return nil
end
--// Alien (not registered) users get blocked:
local report = "\tBlocked from "..user.sName.." ("..
profnam.."):\r\n\t"..data
smDebugToOPs(report)
return 1
end
function smMatchException(data)
if strfind (data, "^$Search%s+(%S+)") then
for _,exceptword in smBlockSearchExceptions do
if strfind (strlower(data), strlower(exceptword)) then
return 1
end
end
end
return nil
end
function IsInLeechList(user)
for i,v in LetLeech do
if i == user.sName then return 1 end
end
return nil
end
function smDebugToOPs(data)
if smDebugging == "1" then
SendToOps(smBot,data)
end
end
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Secure hubs - fail to protect against 0.401
Foxp wrote:Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile)
...
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.
and
And? Nowhere in here do I say it was a bug, just that we have tested this (with over 18 clients and many versions of same) and the only one we get the problem with is 0.401. My statement stands. Just that it's a problem, and that is also true. There are 10 people working on this problem at the moment that I'm aware of, doing cross-testing every 15 minutes or so all hours of the day and night, the stantment stands. DC++ 0.401 is the only issue, regardless of others saying it has always been a problem with all past versions, nope, never has been and we test regularly.GargoyleMT wrote:Foxp wrote:Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile)
...
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.
Now don't mistake here, this is mostly a team of seasoned programmers and testers, several of whom have been coding and working protocols likely longer than many of you have been alive. Myself included, I'm a e-learning developer specializing in new protocol development for e-learning application and management, not some rookie teen just out of school.
If you can't offer facts and reasonable suggestions you are only part of a global problem of wasted internet users and will always be users. Obviously I'm not directing this at you but rather those interested in providing the best security for the users (however underserving in this case) overall.
Fox
-
- Posts: 506
- Joined: 2003-01-03 07:33
the person who wrote that script has no knowledge about how the dc-protocol works. If he/she did, then this would not be an issue since its extremly easy to solve. Study the protocol and it will become clear to you. Hint, examine active/passive users and $Direction.
how-many-people-do-you-need-to-write-a-broken-script-ly'ers? (Apperently 10) ;))
how-many-people-do-you-need-to-write-a-broken-script-ly'ers? (Apperently 10) ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: and
$Direction is caught in UserConnection.cpp. An event is fired, UserConnectionListener::DIRECTION, which is caught in ConnectionManager.cpp/ Please have your team of programmers verify that 0.401 included no change to the way this protocol command is handled.Foxp wrote:If you can't offer facts ...
Whether DC++ 0.401 behaves differently from other versions is an unimportant side issue.
More centrally, the original poster is now asking for a (possibly nonexistent) change in DC++'s behaviour to be reverted to provide what would become illusory client-side security. If nothing else, what if people just use DC++ 0.401? This is why I made my previous comment.
But of course, I'm sure I'm just a basic leecher, one of them "wasted internet users".
More centrally, the original poster is now asking for a (possibly nonexistent) change in DC++'s behaviour to be reverted to provide what would become illusory client-side security. If nothing else, what if people just use DC++ 0.401? This is why I made my previous comment.
But of course, I'm sure I'm just a basic leecher, one of them "wasted internet users".
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
w00t, more Hall of Fame material :)
Foxp: for you information, that leechblocker script that you are using was created after someone saw it (actually it limited <25GB sharing users from downloading from users with a >25GB share) running in my DCH++ hub. I know, because I've read and posted in that thread on the PtokaX board back then. (I'm not claiming originality, I stole the idea from someone else). when I wrote it, I knew that this was a problem and has been for every client out there, unless the client cheats on the $Direction command. the only bug I see is that this was not documented in the script.
I see two fixes for your situation:
- don't download from unregged users at all, unless you share nothing.
- mod your hub to convey information about who is unregistered to dc++. and mod dc++ to fetch that info and use it to refuse uploads. luckily you have a team of seasoned programmers, so that should be a piece of cake :)
P.S. to prevent further undocumented "security issues", you should note that when modding dc++, you'll also need to check the connecting users IP (use $UserIP hub support for this), otherwise the connecting user can lie about his/her nickname and fetch files after all.
Foxp: for you information, that leechblocker script that you are using was created after someone saw it (actually it limited <25GB sharing users from downloading from users with a >25GB share) running in my DCH++ hub. I know, because I've read and posted in that thread on the PtokaX board back then. (I'm not claiming originality, I stole the idea from someone else). when I wrote it, I knew that this was a problem and has been for every client out there, unless the client cheats on the $Direction command. the only bug I see is that this was not documented in the script.
I see two fixes for your situation:
- don't download from unregged users at all, unless you share nothing.
- mod your hub to convey information about who is unregistered to dc++. and mod dc++ to fetch that info and use it to refuse uploads. luckily you have a team of seasoned programmers, so that should be a piece of cake :)
P.S. to prevent further undocumented "security issues", you should note that when modding dc++, you'll also need to check the connecting users IP (use $UserIP hub support for this), otherwise the connecting user can lie about his/her nickname and fetch files after all.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)