94

However, after putting some thought into it I can't come up with a reason why shared executable code on an internal server shouldn't have 777 permissions. Because you're not only trusting every user - which might be reasonable on an internal server where "everybody" who has access should have that control - you're also trusting every process on that ...


28

A call to fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”. A common example of TOCTOU vulnerability is checking access permissions with access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a ...


25

I'm gonna second @gowenfawr and say that breeding better chimpanzees is a goal unto itself here. (now I will extrapolate wildly about your corporate culture) At my software development company, we've been seeing an increasing trend of customers asking for evidence of our security practices not just in production environments, but also in our development ...


7

Unless the program requires write permissions, I am confused as to why your coworker used chmod -R 777 /opt/path/to/shared/folder when chmod -R 775 /opt/path/to/shared/folder would still allow read and execute permissions, and achieve the desired access. Given your team members are the only ones with access to the server, and you trust them. Having global ...


3

Servers are not written in a way to automatically modify a file just with a simple POST or PATCH method, a security feature, to be sure, so 777's biggest threat is that it does expose read-access to potentially sensitive data. Depending on the server configuration, a 777 file could also be executable, though most server configurations limit execution to "bin"...


2

In a world where locks would be unbreakable, no one would have more than one on their house main door. Unfortunately... IT world is not really different. Your OS and server software should not allow a client user to do more than is expected. But there can be security or implementation flaws causing unexpected behaviour... That is the reason why good ...


1

Solution-1 Enterprise & The Right Way Check the steps listed below. Prepare you information classification (public, private, internal only, etc.) Define which type of data will be at which classification level Define the permission strategy, define how you will identify who can do what at which doc. (object/subject/action matrix) Deploy a file sharing ...


1

Firefox solution: You can disable permissions for cameras by going to options -> privacy & security (or type about:preferences#privacy into the URL bar) and look under the permissions header. There you can disable for all website by default and whitelist etc. Linux solution: Disable the uvcvideo module by modprobe -r uvcvideo. This will disable until ...


1

Your site was probably attacked using the last PHP vulnerability on File Operation Induced Unserialization via the phar:// Stream Wrapper. In short, it's possible to upload a valid Phar archive to the server, and trigger a file operation on that file. If this wasn't the route used, check if any of your plugins are outdated, they are the primary suspects on ...


1

If everone who needs to remove or rename files can do so via the shell and you don't need arbitrary programs to be able to rename/unlink files then you can combine sudo and the sticky bit for this effect. Set the sticky bit on the directory. Set the directory to be owned by a dedicated user. Grant everyone bar the restricted user the ability to execute rm ...


1

I have spent considerable time analyzing JPEG embedded thumbnails to speedup image comparison. The conclusions are the following: Some JPEG images do contain thumbnails of original unedited pictures. E.g. images before cropping, rotating, and retouching. Thumbnails are almost always produced by modern mobile phones and digital cameras. Recent cameras ...


Only top voted, non community-wiki answers of a minimum length are eligible