Recently this vulnerability was flagged on Jetty.
CVE-2020-27216
In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.
My question is regarding windows. Is that an issue on windows?
Because of 'on Unix like systems, the system's temporary directory is shared between all users on that system.'
I couldn't find anything to support that windows has something like this.
https://superuser.com/questions/906023/temp-directory-for-all-users
But again some people mentioned that it depends on application as well. So how can I decide whether its a security vulnerability on windows 2016 server.
Regards
Depends on your system.
Run the command (on the command line) ...
> java -XshowSettings:properties --version
Look for the java.io.tmpdir value, if it points to %SYSTEMROOT%\Temp (or other non-user specific directory) then you are vulnerable.
Related
I have installed a window application on a machine. When i run exe file and try to read value from config file, it gives different results for different users.
What I have identified:
config file is saved in user's folder not in the application folder in program files.
it pickup setting for different users from local folder :
C:\Users\myUser\AppData\Local\VirtualStore\Program Files (x86)\Parentfolder\ApplicationName
It seems to me that the application was designed to INTENTIONALLY use the users AppData folder to store its settings. It's generally a bad idea to mess with how a program was designed to operate.
HOWEVER, if you have the ability to run a different program that can do file syncing between different machines on the network, you can certainly do something like make a single copy of the config file and put it into a folder somewhere on the network - preferably on a file server, then use a file syncing program and set it up to take that one file and copy it out to each users workstation and drop it into that AppData folder.
Then, you would only need to make a change to that one file and the file sync software will see that it was changed, then it will copy the new file out to the users' workstations.
Here is a link to a site that reviews a bunch of different Windows programs that do file synchronization ... there are probably thousands of options out there ... just google around and find something that works for you in your environment.
By the way, if you go this route, I would make sure that any time you change the config file so that it copies out to the user's workstations, that the users shut down the program until the file has been copied to their workstation. It's possible that the software could have open locks on the file or that changing it while the software is running might piss it off ... so it's just good measure to shut the programs down, then sync the file then have them launch the program again.
Is it possible to append/remove a ressource file to a binary at execution time?
I have an application written with go, which saves/searches data from a database file, and i would like this database file to be embedded to the binary, and updated by the application itself.
This way the application would be self contained with its database.
Modifying the executable, this is generally a very bad idea.
Several issues pop right into my head, such as:
Does the current user have sufficient permissions?
Is the file locked during execution?
What about multiple running instances of the application?
Even if you manage to do just that, think of what anti-virus and firewall applications will say to it: most when they detect the change will flag the executable and/or contain it, or deny running it, or some may even delete it. Rightfully, as this is what many viruses do: modify existing executables.
Also virus scanner databases maintain reports where files (their contents) are identified based on the hash of their content. Modifying the executable will naturally change the file content hash, thus render the file unknown / suspicious to these databases.
As mentioned, just write / cache data in separate file(s), preferably in user's home folder or in the application folder (next to the executable, optionally in sub-folders). Or make the cache file / folder a changeable option (command line flags).
Technically, this is possible, but this is a bad idea. Your application could be run by users not having write permissions to your binary.
If you're talking about a portable app, your best option might be using a file in the same directory the binary is located, otherwise - use the user's home directory according to the conventions of the OS you're running on. You can use the os/user package to find the home directory.
Hi I am trying to find out what is the best location to save a cache file.
I have an Windows form application that updates user's data from the server using a custom tool.
I want to write the timestamp of the latest updates done on user's machine in the cache file.
Where is the best location for keeping this file:
1. in application directory (c:\program files..)
2. in a temp location e.g. Users profile folder or c:\windows\temp
3. in any location (e.g. c:\dataupdates) where user has full access to read/write to.
Not in the application directory. That much is clear. :) The application directory shouldn't even be writable by the program (or actually by the user account that runs the program). Although some applications still use this location, it has actually been deprecated since Windows 95, I believe, and it has become a real pain since the more rigid UAC applied in Windows Vista and 7.
So the most obvious options are:
The temp folder, which is for temporary files. Note however, that you will need to clean those files up. Temp folder is not automatically cleared by default, so adding new files all the time will consume increasingly much space on the hard drive. On the other hand, some users do clear their temp folders, or may have scripts installed that do that for them, so you cannot trust such files to remain. Also, this is not always C:\Temp of whatever. You'll have to ask Windows what the location is.
You can pick 'any' location. Note that you cannot write anywhere. You cannot even expect the C drive to exist. If you choose this, then you have to make it a configurable setting.
The %app data% directory, my personal favorite, which is a special directory for applications to store their data in. The advantage is, that you can ask Windows for this location, and you can make up a relative path based on that directory, so you don't really have to make it an application setting. For more info on how to get it, see also this question: C# getting the path of %AppData%
I would definitely choose the App Data path for this purpose.
As pointed out in Writing config file in C:\Program Files (x86)\MyApp\myapp.cfg, vs. Administrator privilege, it is not a good idea to write a config file in C:\Program Files (x86)\MyApp\myapp.cfg.
Instead of this, my software now saves its data in a subdir of %ALLUSERSPROFILE% (ex : C:\ProgramData\MyApp\myapp.cfg on Win7)
[I use myfile = open(filename, 'a') in Python to do this.]
I now encounter an issue about this file :
I installed the software with User A, and ran it, then the file C:\ProgramData\MyApp\myapp.cfg was written.
Then, I changed user to User B, and ran my software again : now an error is displayed : User 2 has no right to write in C:\ProgramData\MyApp\myapp.cfg (Permission denied).
Why? Isn't %ALLUSERSPROFILE% a place that can be written by all users?
How to solve this problem ?
No, C:\ProgramData, aka FOLDERID_ProgramData, has restricted security settings. Standard users can create files there. But these files are, by default, secured so that only the user that created the file can subsequently modify the file.
The recommended solution is for your installer to create a sub directory of C:\ProgramData for your shared storage. And that sub directory must be given a permissive ACL by the installation program. That is what grants the desired access to all standard users.
I do wonder whether you really need shared writeable data. Normally I'd expect to see shared configuration be something that is specified at install time and modified infrequently by administrators. Most configuration data tends to be per user.
I'd like to add onto this as I was having issues writing to C:\ProgramData as well. My issue ended up being that my directory/files within C:\ProgramData were written by an administrator. When my app ran under a normal user it was unable to write there so Windows automatically used C:\Users\fooface\AppData\Local\VirtualStore\ProgramData instead. I found the path it was writing to by using process monitor on my application. After seeing this I deleted the files out of C:\ProgramData and ran my app again and it wrote there as expected.
Hope this helps someone.
I have an application that I've written for Windows which I am porting to Linux (Ubuntu to be specific). The problem is that I have always just used Linux, never really developed for it. More specifically, I dont understand the fundamental layout of the system. For example, where should I install my software? I want it to be accessible to all users, but I need write permission to the area to edit my data files. Furthermore, how can I determine in a programmatic way, where the software was installed (not simply where its being called from)? In windows, I use the registry to locate my configuration file which has all of the relevant information, but there is no registry in Linux. Thanks!
The Filesystem Hierarchy Standard (misnamed -- it is not a standard) will be very helpful to you; it clearly describes administrator preferences for where data should live.
Since you're first packaging your software, I'd like to recommend doing very little. Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD, etc., all have their own little idiosyncrasies about how software should be best packaged.
Building
Your best bet is to provide a source tarball that builds and hope users or packagers for those distributions pick it up and package it for you. Users will probably be fine with downloading a tarball, unpacking, compiling, and installing.
For building your software, make(1) is the usual standard. Other tools exists, but this one is available everywhere, and pretty reasonable. (Even if the syntax is cranky.) Users will expect to be able to run: make ; make install or ./configure ; make ; make install to build and install your software into /usr/local by default. (./configure is part of the autotools toolchain; especially nice for providing ./configure --prefix=/opt/foo to allow users to change where the software gets installed with one command line parameter. I'd try to avoid the autotools as far as you can, but at some point, it is easier to write portable software with them than without them.)
Packaging
If you really do want to provide one-stop-packaging, then the Debian Policy Manual will provide the canonical rules for how to package your software. The Debian New Maintainers Guide will provide a kinder, gentler, walkthrough of the tools unique to building packages for Debian and Debian-derived systems.
Ubuntu's Packaging Guide may have details specific to Ubuntu. (I haven't read it yet.)
Configuration
When it comes to your application's configuration file, typically a file is stored in /etc/<foo> where <foo> represents the program / package. See /etc/resolv.conf for details on name resolution, /etc/fstab for a list of devices that contain filesystems and where to mount them, /etc/sudoers for the sudo(8) configuration, /etc/apt/ for the apt(8) package management system, etc.
Sometimes applications also provide per-user configuration; those config files are often stored in ~/.foorc or ~/.foo/, in case an entire directory is more useful than a file. (See ~/.vim/, ~/.mozilla/, ~/.profile, etc.)
If you also wanted to provide a -c <filename> command line option to tell your program to use a non-standard configuration file, that sometimes comes in real handy. (Especially if your users can run foo -c /dev/null to start up with completely default configuration.)
Data files
Users will store their data in their home directory. You don't need to do anything about this; just be sure to start your directory navigation boxes with getenv("HOME") or load your configuration files via sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); or something similar. (They won't have permissions to write anywhere but their home directory and /tmp/ at most sites.)
Sometimes all the data can be stored in a hidden file or directory; ssh(1) for example, keeps all its data in ~/.ssh/. Typically, users want the default kry name from ssh-keygen(1) so ssh-agent(1) can find the key with the minimum of fuss. (It uses ~/.ssh/id_rsa by default.) The shotwell(1) photo manager provides a managed experience, similar to iPhoto.app from Apple. It lets users choose a starting directory, but otherwise organizes files and directories within as it sees fit.
If your application is a general purpose program, you'll probably let your users select their own filenames. If they want to store data directly to a memory stick mounted in /dev or /media or a remote filesystem mounted into /automount/blah, their home directories, a /srv/ directory for content served on the machine, or /tmp/, let them. It's up to users to pick reasonable filenames and directories for their data. It is up to users to have proper permissions already. (Don't try to provide mechanisms for users to write in locations they don't have privileges.)
Application file installation and ownership
There are two common ways to install an application on a Linux system:
The administrator installs it once, for everyone. This is usual. The programs are owned by root or bin or adm or some similar account. The programs run as whichever user executes them, so they get the user's privileges for creating and reading files. If they are packaged with distribution packaging files, executables will typically live in /usr/bin/, libraries in /usr/lib/, and non-object-files (images, schemas, etc.) will live in /usr/share/. (/bin/ and /lib/ are for applications needed at early boot or for rescue environments. /usr might be common to all machines in a network, mounted read-only late in the boot up process.) (See the FHS for full details.)
If the programs are unpackaged, then /usr/local/ will be the starting point: /usr/local/bin/, /usr/local/lib/, /usr/local/share/, etc. Some administrators prefer /opt/.
Users install applications into their home directory. This is less common, but many users will have a ~/bin/ directory where they store shell scripts or programs they write, or link in programs from a ~/Local/<foo>/ directory. (There is nothing magic about that name. It was just the first thing I thought of years ago. Others choose other names.) This is where ./configure --prefix=~/Local/blah pays for itself.)
In Linux, everything is text i.e. ASCII.
Configuration is stored in configuration files which normally have .conf extension and stored in /etc folder.
The executable of your application normally resides in /usr/bin folder. The data files of your application can go to /usr/lib or folder in /usr/ folder.
It is important to consider which language you are writing your application in. In C/C++ a custom makefile is used to do installation which copies these files in respective folders. The location of installation can be tracked by tracking the .conf file and storing the location while generation using bash script.
You should really know bash scripting in order to automate this everything.