[McAfee]

If a remote end can easily inject fake information leading to the user getting viruses, trojans, etc. Then it's a security risk.
The default installation of eMule will cause that situation to happen, the solution you intend is a "workaround" requiring the user to follow unofficial steps in some forum. At least issue a Security Risk notice and official guide on how to configure eMule so that such situation doesn't happen.

You obviously haven't searched with broken servers in list in a long time. The search terms are simply not respected, if I'm using filters cd-images (for example) why am I getting files with EXE extension? I may still get bad/fake content but If I searched for Videos, let the fake content be (search terms).avi and not some executable like it is now. That is just broken!

The risk of someone who searches ONLY for media files would be much lower. Even if they get fake media, they at least wouldn't get a fake executable.

Your search terms are passed to the server, and the information that comes back is trusted 100%, no 2nd pass is done. Only few filters which are purely processed by eMule are passed on the results, but those that formed part of the original query are not re-checked.

There is a difference between Google occasionally feeding you a bad url, then google feeding you 10 pages of bad links from top to bottom, only to have the first legitimate url obscured way after, you simply will not find the legitimate page at all, and the service would just fail. Thus google would never let that happen. Note that Google is not the best example their search terms are all processed by one entity, not split between server and client. But is just an example of how software has to keep evolving to stop hackers from having their way. (http://en.wikipedia.org/wiki/Search_engine_optimization#White_hat_versus_black_hat)

EDIT:

OK I retested emule on a VM, and the scenario doesn't seem to happen on a default install, which is better that what I originally thought. But I still think that I use g a filter for certain media files, it should stick and not give back an EXE.

This post has been edited by McAfee: 31 March 2012 - 12:05 PM

[Stulle]

Again, this is not due to eMules fault but due to the servers fault. To give you an example, if you search for "Justin Bieber" on Google and you get the suggestion "Justin Bieber killing babies" it's likely a search injection by no-goods. If you then proceed to that suggested site and download "ProofVideo.exe" you are not just moronic but likely about to get serious computer trouble.

So is Google broken because someone exploits its functionality? Not really. If somebody trusts a remote server enough to be in his server list it is his own fault if he trusts the search results that server sends. Just like it's your own fault if you trust anything Google responds. There really is no difference except that people would stop using Google if they were not giving anything but shit. Well, consider not allowing fake servers into your server list and hence trusting them.

Again, this is not a bug. A bug would be if no server or KAD searches were possible. It can be considered a discomfort if some of the provided functionality is providing unfortunate behaviour but a discomfort does not equal a bug.

Also note that I am not closing my eyes. I have been an advocate against using servers for a few years now. The server development has been dead for years now and if anyone still considers using them I consider it to be entirely their problem. For all I care the whole server stuff could be scrapped and removed because KAD is superior in so many ways. Besides, there is no real fix for trusted servers providing search results. The protocol is not intended to differentiate between the content of files because only a client who has the entire file can actually verify the validity of a file name. In regards to the file extension the code says this:

	// here we have two choices
	//	- if the server/client sent us a filetype, we could use it (though it could be wrong)
	//	- we always trust our filetype list and determine the filetype by the extension of the file
	//
	// if we received a filetype from server, we use it.
	// if we did not receive a filetype, we determine it by examining the file's extension.
	//
	// but, in no case, we will use the receive file type when adding this search result to the download queue, to avoid
	// that we are using 'wrong' file types in part files. (this has to be handled when creating the part files)

So you might want to suggest a feature that distrusts the servers some more but this is clearly not a bug report but a change of behaviour. I, however, can see why the servers were trusted back when the code was written. Among those reasons would be the lack of fake servers, for instance. Also note that retrieving the file type from the file extension is a very bad habit because the file name is only cosmetics in the eD2k. Like I said, no server could verify or falsify my claim that "ProofVideo.exe" is really an executable. So why bother and waste resources on retrieving the file type from the file name if it's just as untrustworthy as the file type we were sent by the eD2k server? No point, really!

The only real way to prevent fake results from flooding the search is eliminating the source. If you can come up with a reliable algorithm that will exclude fake servers feel free to share. Until then just don't use servers or only use proper servers.

Edit: Nice edit, mate... Now it's not just not a bug but apparently also an illegitimate complaint...

This post has been edited by Stulle: 31 March 2012 - 12:23 PM

[Some Support]

McAfee, on 31 March 2012 - 07:33 AM, said:

Suggested Fix:
eMule shouldn't take search results from the servers as authoritative information and should further enforce the filters used upon the response received.

Unfortunatly that isn't really going to help. We tell the server exactly what we are looking for, so if the server itself is malicious, it can just produce search results which fit our request and it would still be full of spam. The only one criterium which can indeed be enforced is a filesize filter, but even then a spammer can just prepare several files in the most common sizes - and most users don't use a filesize for searching anyway (actually i'm not sure if eMule does it already for filesizes and a bit too lazy to look it up).

For Kad we already do such sanitizing for search results and due to the different technology it works a lot better there. But for servers you are pretty much out of luck if you are connected to a fake one in terms of searching.

[xilolee]

Anyway he has got a point...
For example, when we are searching "archive" files, results should not have a bitrate, length or codec...
When we are searching audio/video files, users miss a checkbox like "remove wmaudio/wmv codec and extensions"
I'm using only advanced search with @parameters, but only few users know it (and know how to use it)

[DavidXanatos]

How about doing some basic sanity check on the results as xiolee described and if the most files fail this check just display:
"Server returned bullshit, please don't use fake servers"

David X.

[xilolee]

Unfortunately, this happens with legit servers (not only with fake servers), only edonkey2 filters in some way wma/wmv files, other servers have never done this...

PS: KAD has got the same problem!

This post has been edited by xilolee: 31 March 2012 - 02:37 PM

[Stulle]

I don't see your problem with windows media format files. They are just as much audio/ video files as any mp3 or mpg file.

Anyway, just blindly filtering is not the cure. Like I said, there is no way to verify a files content until you at least have some parts of it. So the question is do we censor search results if we believe them to be fishy or do we let the user make the choice. Personally, I would not want to automatically meddle with the search results too much. There are thousands of ways to get the proper result for any search and just prohibiting some stuff might have unfortunate results for other users. Also, I do think that it is somewhat necessary that the program trusts the eD2k servers in the server list. Anything else has to be the user.

This post has been edited by Stulle: 31 March 2012 - 03:31 PM

[xilolee]

Because 99% are fakes....

I always use something like (for example for songs):

@bit>127 @bit<321 @siz>2 @siz<15 @len>2m @len<15m @ext=!wma,!wmv -@cod=wmaudio2 -@cod=wmv3

That it is not exactly user friendly

The same applies to films

Instead for archives:

@bit<1 @len<1

This post has been edited by xilolee: 31 March 2012 - 03:38 PM

[Stulle]

I don't even get as far as having to bother with stuff like that. The only kind of spam I ever get on KAD searches is a bunch of small archives and executables which I don't bother with because I got a good idea how many sources should exist and how large the file should be. Just a bit of common sense, really. No fancy parameters or even file type choice... Also, the best search is still the one backed by a community that shares links, if you catch my drift.

[xilolee]

Try reading irc channels and you'll see how many users have those problems.
Anyway, i can always search and find the files of those communities with emule, because they should connect to server or kad networks...
In other words, I'm not registered to any community. But I find the files i want...
As long as the search has these problems, users will choose other networks...

This post has been edited by xilolee: 31 March 2012 - 03:50 PM

[DavidXanatos]

The best way to stop this problem would be to abandon servers at all.

David X.

[Stulle]

What other significant network is there that provides an inbuilt search and such a diversified set of files? Torrent? Well, if I need a torrent tracker site to find a torrent I can just as well get my eD2k links from a site.

Other than that... I am not too welcome on the official Mindforge eMule channels... I wonder how that happened... :-D

[xilolee]

DavidXanatos, on 31 March 2012 - 05:54 PM, said:

The best way to stop this problem would be to abandon servers at all.

David X.

(does imageshack.us require registration now?? used tinypic.com)

Searching videos (kad network):




Serching songs (kad network):





First seven results (availability): 3 requests of codec, 1 renamed file, 3 working = good results under 50%

Stulle, on 31 March 2012 - 06:15 PM, said:

What other significant network is there that provides an inbuilt search and such a diversified set of files? Torrent? Well, if I need a torrent tracker site to find a torrent I can just as well get my eD2k links from a site.

Users are decreasing month by month, week by week...

Stulle, on 31 March 2012 - 06:15 PM, said:

Other than that... I am not too welcome on the official Mindforge eMule channels... I wonder how that happened... :-D

I am not welcome too, but they can not ban me... I think you know how to do the same

This post has been edited by xilolee: 31 March 2012 - 04:52 PM

[tHeWiZaRdOfDoS]

xilolee, on 31 March 2012 - 03:00 PM, said:

Anyway he has got a point...
For example, when we are searching "archive" files, results should not have a bitrate, length or codec...

IIRC that's what Netfinity's Fakealyzer does already... out there for...? 2 years at least... also filters those 951 (1) availability files nicely.

[Stulle]

Yeah, although it just gives visual feedback which I quite like about it. Although I found out that apparently some people don't like the visual feedback either. Anyway, if someone were to change something it should be something like this. Not omitting results only enhancing them with useful information.

[McAfee]

If the filters used for the search had type set to "Video" it should not give back files with extension .avi.exe

I understand the concept of judging files by their contents and not extension, like Linux does for example. But an ed2k link as complete as it may be, simply does not have enough information to do this. So using the file extension, like windows does, may be a good thing to do at that point.

It's probably safer to get an .avi file that actually is a .exe with the wrong extension, compared to getting an .exe when the search results have not even have that in the output.

While operating systems like Linux will ignore the extension and run files by their content. Windows on the other hand will keep to the extension. So the first file is just going to give an error on the video player associated with it, but it will not run as a program.

The 2nd file on the other hand:
Default windows installation typically hides extensions (a choice I don't agree with) So such files would look to the user as ending in .avi, the program icon may be anything the author decided, so he could have put the icon of a video...

Most of us here have been using eMule (and computers) for a while, and won't fall into such traps. But can we suggest eMule to anyone without having a sense that they may get bad files with ease.

I just think there could be an extra layer of security regarding the download of executable files when the user clearly did not intend to download executable files.

What do those type filters do anyway?

[Some Support]

The file type in eMule is defined by the publisher. This is because the file name in eMule is really just supposed to be a name and given that one file can have hundrets of names, determining the type based on one of those names is not ideal.

Now I agree, that this is a bit annoying for *.avi.exe files - however indpended from the OS setting, eMule will never hide the extension, so every user who knows what .exe means can reevaluate if he really wants to download this file. Additionally, once the download started and data gets in, eMule will try to verify the file type (well actually it tries to verify that the windows extension fits its content, so this doesn't really applies in the double extension case). If it doesn't matches, a warning sign will apear in the download list. eMule also sets the "downloaded from the internet" bit on the file, so once you click on it to start it, Windows will ask you to verify the you really want to execute that file and that it might be dangereus.

This isn't completely fool proof, but changing it to file based on file names has other disadvantages.

[Meuh6879]

xilolee, on 31 March 2012 - 04:36 PM, said:

Because 99% are fakes....

the problem is that's 1% on WMV are from Japanese source and they are valid (moviemaker source).
on a precise subject, you have only WMV valid file (without DRM integrated).

eMule is like that.

[Meuh6879]

xilolee, on 31 March 2012 - 05:37 PM, said:

Yes, you must request a code (must login) to upload max 500 files (free).
After this, you must pay for this service (after the 50

Yes, you must request a code (must login) to upload max 500 files (free).
After this, you must pay for this service (after the 501 file).

[xilolee]

Meuh6879, on 01 April 2012 - 12:36 PM, said:

the problem is that's 1% on WMV are from Japanese source and they are valid (moviemaker source).
on a precise subject, you have only WMV valid file (without DRM integrated).

I don't want those 1% of "good" wma/wmv, i know how to avoid them.
Users don't!
Now, results could be avoided before the search or after it.
A simple checkbox in the search tab "don't search wmaudio/wmv codecs" (before the search) or "remove wmaudio/wmv codecs" (after the search) or a checkbox that works in both cases... could be a solution.

McAfee, on 01 April 2012 - 12:22 AM, said:

What do those type filters do anyway?

What filters?

This post has been edited by xilolee: 01 April 2012 - 11:24 AM