JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 07.06.2010, 16:35
ruinebabines
Guest
 
Posts: n/a
Exclamation Security concern

Could someone please have a look at this post at
hxxp://gladiator-antivirus.com/forum/index.php?showtopic=105566&view=findpost&p=257939
where the security expert Ilya Rabinovich, author of DefenseWall PF, arises some concern about the fact that JDownloader storing its databases and temporary files inside its \Program Files\JDownloader\ folder? It is said there that JDownloader is "not written properly. Under LUA, it's forbidden to store anything into the "Program Files" folder".

Comment?

EDIT: I hope that I place my post in the right sub-forum, if not please advise. And sorry for my lacking english skill.

Last edited by ruinebabines; 07.06.2010 at 22:32.
Reply With Quote
  #2  
Old 08.06.2010, 04:42
tony2long's Avatar
tony2long tony2long is offline
English Supporter
 
Join Date: Jun 2009
Posts: 6,285
Default

It is advised to install JD not in Program Files folder, although it's installer put it there. A change request has been filed: http://svn.jdownloader.org/issues/show/1849
Reply With Quote
  #3  
Old 08.06.2010, 05:25
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

Rabinovich is just reporting that Microsoft changed their mind about how programs should store their data (this is the 5th time). JD is not a security threat.

There is no authority to forbid anything.

We now encourage users to install JDownloader into c:\jdownloader instead of Program Files. I expect that the new installer will fix this. However, this issue is only related to Windows version 6.1, not Vista and earlier.
Reply With Quote
  #4  
Old 08.06.2010, 12:22
ruinebabines
Guest
 
Posts: n/a
Default

Ok, I had not seen there was already a filed request about this matter. Thanks both for your replies.
Reply With Quote
  #5  
Old 08.06.2010, 15:19
ruinebabines
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by drbits View Post
JD is not a security threat.
Just for clarification. The author did not infer by any way that JDownloader was a treat. But DefenseWall labels all internet facing application as "untrusted" simply to be able to best protect a system. Say, if a baddie was downloaded via JD, this malware/virus would automaticly be strictly confined and not be able to do its dirty job to harm your computer. Because DW will then apply strict policies to those untrusted files. Hence why DefenseWall Personal Firewall is call a policy sandbox HIPS.

Btw, I am not associated in any way to this program other than being a satisfied customer of it.
Reply With Quote
  #6  
Old 13.06.2010, 11:52
remi
Guest
 
Posts: n/a
Default

When you tread this thread, you'll know that jD is a treat and not a threat.
Reply With Quote
  #7  
Old 14.06.2010, 08:34
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

Unless DefenseWall informs you that it is doing this and allows the user to opt for a policy on a program by program basis, then DefenseWall will cause more security breaches, not fewer.

The developers of Security software have an underlying assumption that users are stupid and gullible. They therefore try to make the computers "Stupid, gullible user proof". This just irritates users and they turn off the protective features.

Almost every operating system has a sandbox built in. It is called security permissions. These are assigned explicitly on a program by program and user by user basis. When a program is downloaded from the internet, it should have "guest" permissions (r--------).

However, only stupid users would ever download a program from the internet. One always downloads programs as archives and allows the antivirus to scan the program for known bad traits. When the program is removed from the archive, it is usually given Interactive User permissions (r-x-r-x---). The permission level that users should be using for most work is Authorized User (rwxr-x---). That is why the su program and its successors (sudo and UAC) exist, to allow users to run as users and to apply for extended permissions when necessary.

JDownloader itself does not allow others to control your computer or steal data from your computer (unlike BT programs). Some of the addons (remote control and Web interface) can allow an outsider to tell JDownloader to download files you do not want if you set-up your firewall to make those features available to strangers. But, JD never leaks data and never allows others to execute programs.

When a feature is added to allow users to execute programs after an archive is extracted, the user will have to make responsible choices about what to do with that. Automatic execution of what is downloaded is what DW is trying to avoid.

Contrary to common belief, files do not have to be scanned by the antivirus after they are downloaded or extracted. There are many good reasons to run a program after an archive is extracted, but the most common will be to automatically move the files to the correct directory. JDownloader already contains almost all operations of that kind that are necessary.
Reply With Quote
  #8  
Old 14.06.2010, 17:19
eMeR Manix
Guest
 
Posts: n/a
Thumbs down Storing all data under separate "\JDownloader" directory isn't good idea

IMHO storing all data under separate "\JDownloader" directory isn't good idea...

Maybe JD developers can change mind about application private data storage place.
Nowadays most Windows applications changed design, to store their private data under current logged user directories and/or common directory for all users.
IMHO all applications, under any system, should read user environment settings from system internal databases, and then use local storage space allocated for user(s).

According to this rules, running under MS Windows, JD can store data related to only one user, under directory:
Code:
"#Profiles Directory# \ #Current User Directory# \ #Application Data# \ JDownloader"
and data common to whole application (if needed) under directory:
Code:
"#Profiles Directory# \ #All Users# \ #Application Data# \ JDownloader"
Second example should be very usefull if, in the future, JD will act as back-end server task, and is currently often used by antivirus software.

BTW pathes given above must be read from proper system environment variables, I'm not providing here their correct names (I put only their descriptive names).
Reply With Quote
  #9  
Old 15.06.2010, 01:39
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

Yes, this is the recent "best practices" for Designed for Windows "7" programs. Microsoft wavered on this back in the Windows XP days and does not adhere to these guidelines itself.

However, JD is not a Windows program. The plan is to keep it a portable program. Except for the optional registration of some mime types and extensions, JD does not use the registry. All data is stored with the program. This is how Portable programs are designed to work.

The Microsoft %USERPROFILE% and %ALLUSERSPROFILE% are a very bad idea in general. Microsoft is assuming that desktop computers will only have one Hard drive; this has been a bad assumption since the PC-AT.

The registry allows each program to set its program directory and its data directory, the %USERPROFILE% is just a default introduced in Windows 98 to solve a specific problem in the commercial workplace.

They probably will not follow my advice for this release, but I recommended changing the default directory to %SYSTEMDRIVE%\portable\jdownloader\
This would mean that all data for the program is stored in the directory with the program itself.
__________________
Please, in each Forum, Read the Rules!.Helpful Links. Read before posting.
Reply With Quote
  #10  
Old 15.06.2010, 15:01
pspzockerscene's Avatar
pspzockerscene pspzockerscene is offline
Community Manager
 
Join Date: Mar 2009
Location: Deutschland
Posts: 49,345
Default

I on't really like the way it is when you install programms on your Windows PC.
Most programms only work when their registry entries are available so let's say C (your windows) crashes and you re-install it while your programms are installed on another harddrive and another partition.
After the crash the data will still be there but most programms won't ork anymore and you can waste your time re-installing them.

Well just an example, in general i like windows (7) because i am also a gamer.

Sorry for the offtopic:rolleyes:

GreeZ pspzockerscene
__________________

Ad-free installers || Werbefreie Installer
Windows Setup<--JD2 BETA-->Linux Setup x86 || Linux Setup x64 || Mac Setup
-----=>Support Chat<=-----
Spoiler:

A users' JD crashes and the first thing to ask is:
Quote:
Originally Posted by Jiaz View Post
Do you have Nero installed?
That's true James
Quote:
Originally Posted by James
Die Leute verstehen einfach nicht dass nur weil man mit einer Waffe auch auf Menschen schießen kann dass ein Schützenver​ein kein Ort für Amoklaufide​en ist
Reply With Quote
  #11  
Old 15.06.2010, 15:03
eMeR Manix
Guest
 
Posts: n/a
Default

OK. I agree with Your point-of-view, especially concerning portability.
But assuming (hard-coding) "%SystemDrive%" as root folder, looks for me like another mistake.

What if user have no free storage on first drive, and choose to install JD on the third volume?

One should rather use, mentioned elsewhere on JD forum, relative path - embeded under JD install directory (meaningless where JD was installed, and/or from where was started).


BTW my installations of Windows always store ALL user data on the second volume (partition) - thanks to some Windows Installer scripts hacking, so I have usually big space for temporary storage...
Reply With Quote
  #12  
Old 16.06.2010, 10:00
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

The default installation path is just a default presented to the user.
The default data path is just a default a default presented to the user. I personally store my files on various drives, depending on the subject.

The initial security breach discussion is that Microsoft is moving toward keeping MSI installed program files unchangeable except by MSI. This means that files installed into %PROGRAMFILES% will eventually be protected in a way similar to the OS files.

However, this assumes that every program will be installed and uninstalled using MSI. I expect when Windows version 7.0 is released, %PROGRAMFILES% will be protected against unsigned installation and modification. There will be other "Automatic" security protections added as part of the effort to make Windows a reliable OS. Programs like JDownloader will not be allowed to install into %PROGRAMFILES%. The plan is that most programs in Windows 7.0 will run within virtual machines with limited access to the OS or physical resources.

In truth, analysts hired by Microsoft should not be discussing this as a possible security problem in JDownloader. If it is a security problem at all, it is a problem in the design of the operating system. Microsoft is making believe they didn't create this problem 18 years ago.
Reply With Quote
  #13  
Old 16.06.2010, 16:20
eMeR Manix
Guest
 
Posts: n/a
Default

You can look on this, as somewhat higher level of harvard architecture

We not only separate CPU code from data stream over process level, but also we separate aplication "code" files from processed data files over storage level.


Whether it make sense for you?
Reply With Quote
  #14  
Old 17.06.2010, 00:04
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

It makes sense to identify information by security privileges that apply to that information for that "effective" user (takes into account "impersonation" by programs, UAC, etc.). Where you store the information is not relevant.

For example, the Windows directory does not have to be on the same drive as the boot code (mine isn't).

The only advantage of separation of executable code from user data is that antivirus scanners only have to look at the user data with some of the signatures, not all of them. But with rootkits even that becomes unreliable. Since every Sony computer (manufactured during a certain period) has an unremovable rootkit that may hide other rootkits, and many other computers have rootkits, there is no security advantage to positioning of data, except for setting the default security privileges for that directory.

Applications under Windows have several "Segments". Each segment has its own execution privileges. The default build segment is "TEXT" and it has Read, Write, and Execute allowed. This is to allow the linking together of independent routines without worrying about "backpatching" addresses. This is usually the main-line for programs.

There are segments that are read/write (no execute), Some are execute or read (after loader completion), Some are read only (after loader completion), Some are execute only (after loader completion). Modern processors can enforce this on a memory page-by-page basis (so all segments of the same type are loaded into memory together, and the size rounded up to 4096 bytes under Windows).

Scripts, such as Java classes break this. The code is read from disk and written to memory in the heap, and then some is executable, some contains data values, and some is some is automatically initialized, some contains data values, and some is thread stack space. Fortunately, the Java Virtual Machine does a better job of policing the data than the Hardware and OS do. However, under Windows, the JVM is often undermined.
--------------------------------
The most important separation in the CPU between code and data is done to allow pipelining and separate caching of the code from the data. This is done based on looking at each instruction and preloading the next few words of code and the next few words of data after the data that is used by the current instruction. In this case, the words are usually 128 or 256 bits. There are a lot of assumptions made in doing this, and a lot of the time the preloading and part of the pipeline are thrown away.
Reply With Quote
  #15  
Old 17.06.2010, 01:34
eMeR Manix
Guest
 
Posts: n/a
Default

Seeing this issue from coder/programer perspective, such separation isn't so important. But, looking it from manager/administrator Point-of-View, separating "code" of programs from processed "data" can be usefull in many ways.

When storing "code" and "data" on logically disjoint storage one can:
- easilly apply different security/access policies
- backup and/or restore program-files and data-files regardless/independly from each other
- manage (move/rename/remove/recover) data-files of various users in unrelated manner
- repair/recover only important user data after storage failure

This is becoming very important with multi-user approaches, where on same system exist many user-accounts (home/dormitory).
Think, some peoples must share their PC's with parents/kids/spouses/friends/colleagues ect.
As administrator of PC I would prefer to install given application only once for use by all users on one system, but each user should be limited on another user data access.

The best solution there will be, if one download engine can watch for jobs from all existing user accounts (and continuously downlad), but never show foreign jobs to each other.
And, of course, replicated links (if any) should be downloaded only once...

This can be done, if such engine will be installed as system-wide service with system-level privileges, and then do check/acces folders in all user accounts, for designed "default" locations.
By user "jobs" I mean rather links list (URI to file on hoster server). Target storage places of downloaded files should be possible to manage by end-user. This probably should be more-easy with planned, GUI-less server-like JD engine.

Another approach, which I'm dreaming, will be to create spreaded JD installations, (running on multiple PC) possible to be controlled remotelly by many users, but having no any knowledge of each other download "jobs".
Reply With Quote
  #16  
Old 17.06.2010, 10:32
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 66,134
Default

Just a few words about the topic:

1.) the topic about security concern is not very good chosen as i will explain why:

2.) first of all program files folder or any other windows protected folder is no good idea to install jd to (also our installer for windows can setup rights on folder correct). this is because without correct right management the following will happen (thanks to miroshit)
2.1.) jd installed in program files
2.2.) jd writes (eg update or config) - these files will be written into the virtual folder that windows creates (eg c users jiaz anywhere there). this is done transparently by windows, java does not know about that
2.3.) now the real bad design part: if jd reads a file, this read access will not be redirected to the virtual folder, it will still read the old/outdated files from c: program files
2.4.) thats causing the main issue with windows. and there is no way to workaround this except setup rights correct or use non windows folders

3.) seperate config from data
3.1.) will break portabilty, that means now you can move / copy /backup the complete jd folder and it will still work (only have to fix the download folder pathes)
3.2.) with seperation you have to copy 2 folders and the data folder you first have to find
3.3.) many like the portability and not having to reinstall it (just copy back from backup)
3.4.) there is no easy way to find correct config folder as
3.4.1) each user can have its home folder on different places (if user sets so)
3.4.2.) user folder is again protected and virtualized by windows
3.4.3.) name or user folder is not always the same (different languages)
3.4.4.) find out username

4.) seperation does not help with folder virtualization by windows, you still have to setup folder rights correct in order to update jd
4.1.) firewalls have problems with java because of many programms using java.exe but its always the same java.exe...thats why they are disturbted by different things the java.exe does
4.2.) setup firewall/av correct is possible
4.3.) no you will not increase security risk, as jd does NOT execute any code. it will not autostart exes which are downloaded

5.) jd is multi os and only because microsoft thinks that they can dictate and change the rulez from version to version......sorry...i dont have time to play their game (remember the user folder.....once it was c:\windows\profliles, then it was c:\windows\users, now its c:\users......whats next? username:// as its own drive? )

greetings
jiaz

PS: maybe we will add support for config/data seperation but it is very very low prio
__________________
JD-Dev & Server-Admin
Reply With Quote
  #17  
Old 12.10.2010, 23:58
Hazer
Guest
 
Posts: n/a
Default Sorry

Ok, sorry for reopening this thread...

The best way to do this, is making an option on installing, like:
"
How to store your data (options/downloads)?

[x] - Portable way: Everything at the same folder as jdownloader.
[ ] - XP Mode: Options on users appdata folder and downloads on C:\downloads\
[ ] - New Mode: Options on C:\users\appdata and downloads on C:\users\downloads
[ ] - Choose yourself: Choose manually were data will be saved.
"

An option like this when installing its perfect, NO ONE will unlike it, everybody requests will be solved ;D
And mine too o/
I want to use JDownloader in multiples users with different settings...

I know this is possible, but i don't know if its easy. ~i don't belive so~

Sorry again, and if futurelly u guys make it, thanks ^^

Cya~

Last edited by Hazer; 13.10.2010 at 00:01.
Reply With Quote
  #18  
Old 13.10.2010, 09:54
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

The problem with having installation options like that is that it is not portable to other OS.

Changing the default JDownloader directory to C:\programs\jdownloader will solve most of the problems.
Reply With Quote
  #19  
Old 14.10.2010, 19:41
Hazer
Guest
 
Posts: n/a
Default

i see...

So, to make it, will be needed a new one version for windows that can not be updated together the linux/mac one versions, right?

That's really bad @_@

Ok, thanks, too much work for not much help =/
and JDownloader OWNZ
Reply With Quote
  #20  
Old 15.10.2010, 13:38
drbits's Avatar
drbits drbits is offline
JD English Support (inactive)
 
Join Date: Sep 2009
Location: Physically in Los Angeles, CA, USA
Posts: 4,437
Default

I could probably write an MSI installer and MSI Patch creation/installer, but that would be around 2 months of full-time work (I used to do that professionally). Microsoft really fowled things up, only thinking about enterprises, not small groups developing large, dynamic software.

It is a little easier for people developing VB.NET, because that is what the MS development tools are mainly designed for.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 21:21.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.