security issue

PMc

PMc

I noticed what might be a neglegent (world readable) file permission in a ports configuration, concerning a file that might contain private data of the application.

That port is mainly used by web applications. Should I care, and what should i do with that?

Code: 
$ grep umask /usr/src/usr.bin/login/login.conf 
        :umask=022:\
So that's what you get, normally.
 
Have you tried contacting the port's maintainer? Or does this port not have one?
 
It's not a port. It's login(1) and it's just a normal default. You can change the umask in your shell initialization.
 
rbranco said:
It's not a port. It's login(1) and it's just a normal default. You can change the umask in your shell initialization.
Click to expand...

Yes, *I* can do that. I can also walk my directories and see if they have proper perms - because I know my unix.

But others maybe not. They install a web application, the application says it has a prereq, they find that prereq in ports, install it, and their application starts to work. They will never glance through all the individual directories that the various prereqs have created for their own business.

And I don't tell you here *which* application is concerned, because I see what kind of scanning requests come into my webserver already. (The grep from login is just the proof that our official default is indeed to install files world-readable.)
 
There is no default to install (create) files world‑readable. The open(2) system call requires a mode_t value if it is meant to create non‑existent files (O_CREAT flag; without it it fails for non‑existent files). There is no automagic provision of a fallback value.​

The explicitly requested mode is then subject to the process’s current umask value. So, although you want to open a new file with the mode 666 the umask value of 022 strips the write permission for group and other. Thus the new file possesses the mode 644 although 666 was desired.

You probably know all that, PMc, so it’s a recap for other readers, but my point is: If it matters the requested mode should not be too liberal to begin with. Therefore I recommend informing the port maintainers about the potential security issue.​
Bash: 
mkdir  -m 700 my_directory  # `mkdir` utility usually requests `0777`
mkfifo -m 600 my_named_pipe # `mkfifo` utility usually requests `0666`
# no universal/portable utility for creating regular files with certain mode
 
Kai Burghardt said:
You probably know all that, PMc, so it’s a recap for other readers, but my point is: If it matters the requested mode should not be too liberal to begin with. Therefore I recommend informing the port maintainers about the potential security issue.​
Click to expand...
Agreed, that's done already. And no, I don't know all this by heart, I just know where to read it up when needed. Anyway, applications nowadays tend to be well designed insofar that they don't use the same key for every task, but different ones that are derived from a master key. But if then I find that master key end up in a world-readable file, that's where I am getting interested. Figuring out how this can happen is still another step, my first question was just what to do about it (besides fixing that on my own sites). Then also, this concerns mainly those people who might also manage to post their master key to Github - so I was undecided if one should do anything at all.

Just had a look into the source - seems they're using fopen().
 
Sounds like the issue might need to be fixed in the upstream application. Because it generates these files with too liberal permissions to begin with. It also sounds like they're accessible from the webroot too. That's not good either.
 
PMc said:
Yes, *I* can do that. I can also walk my directories and see if they have proper perms - because I know my unix.

But others maybe not. They install a web application, the application says it has a prereq, they find that prereq in ports, install it, and their application starts to work. They will never glance through all the individual directories that the various prereqs have created for their own business.

And I don't tell you here *which* application is concerned, because I see what kind of scanning requests come into my webserver already. (The grep from login is just the proof that our official default is indeed to install files world-readable.)
Click to expand...
This default applies only to login(8) as default umask, and not an "official default" for installations of any kind.
 
SirDice said:
It also sounds like they're accessible from the webroot too. That's not good either.
Click to expand...
No, that should not be able to happen (otoh we know of enough badly configured webservers).
Anyway, the protection is by usng two different users (and you're allowed to laugh now).
 
Okay, besides writing to our port maintainer, I have reported to one of the concerned application which uses that port to store sensitive data. They have declared the matter as off-topic to them, and deleted the report.
 
You must log in or register to reply here.
Back
Top