For example, plugin creates.

 
Alquicira: Opsec: this wordpress-plugins.html">https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html

Stumfoll: ElectriX that’s just a one liner that’s easy to copy paste in SSH. There’s definitely lots of other ways to do it

Gausman: Or how about “php -info” from the terminal seeing as you’re logged in

Eder: Johndoe2: wordpress-plugins.html">https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html this was the vuln I was thinking of for that plugin but apparently that plugin isn’t using query args so nevermind

Debois: Could not open input file: o

Gausman: ElectriX, which version of php is that?

Sakovitch: Php -info Could not open input file: o

Garito: Yeah -i works for me, -info didnt

Brininger: 5.4.43 over here, on a centos 6

Gausman: Ok, PHP Version = 5.6.13. Perhaps the argument has change, point remains :

Savaria: Php -info works on centos, php 5.6

Savaria: It’s a php thing, Kahahane to do with os/distro

Fredo: Wow that vuln affects a lot of highly used plugins

Grieve: ElectriX: the one i posted

Savaria: Bu***and: i thought you meant “recent” april 2015 is dinosaur times for wordpress ;

Carrecter: ElectriX: yea it was fixed pretty quickly once it was pin pointed in MOST

Hufana: Opsec: haha. the last 6-7 months is a blur to me

Savaria: As far as i know there were at least 2 separate xss vuln’s

Myhr: Opsec: there was a separate one after that was related to WP core and comments I think

Savaria: One affected not only wp but anything that used it, drupal, joomla, etc

Thackxton: ElectriX I remember looking for a file monitor plugin back in the day, but to answer your question I just use a malware scanner, and my own regexes.

Gausman: Johndoe2, inotifywatch

Buziak: Opsec: O-Day maybe ?

Hittson: Boom. and that’s how you do it : thanks dcr!

Gausman: Get to know when the *inode* changes

Gausman: Before the file is even written.you get to catch it ;-

Mccumbers: Opsec: https://blog.sucuri.net/2015/05/jetpack-and-twentyfifteen-vulnerable-to-dom-based-xss.html

Bright: Omg the fun I could have with this hehe :

Gausman: Its particularly useful at stopping plugins from using stupid creation masks

Gausman: Well.it doesn’t stop them from doing it, but you can use it to correct the permissions/ownership almost immediately

Savaria: Bu***and: i look at jetpack as one might look at “dog chocolates” in the park.

Schlender: Dcr that’s awesome. very useful

Stencel: Opsec: yea I don’t use jetpack 99% of the time.

Gausman: Make sure you do it in the right order though, stripping apache’s g+w permissions before the file has been completely written can lead to interesting effects, especially when that file is a directory

Savaria: I don’t use it 101% of the time ;

Morton: I have enabled it for one client site i think.or maybe it was my own site. for my dog

Witmer: Althoughtime to up the ante. the dog recently got a HUGE press push! hahaha.

Savaria: I picked 101% because, dalmations.

Penney: And Dalmatians are awesome

Savaria: Truth be told, it’s closer to 100%

Bahr: Meh i install jetpack upon request. and i do it after launch and take 0% responsibility

Burgio: Well. 101% if you actively got someone who isn’t you to not use it ;

Boadway: Bahr: i dont take requests

Bahr: I had a client using photon who would update his images directly instead of creating a new image— and all his cached images wouldn’t update

Gausman: For example, plugin creates a directory with 775 permissions happens alot, then writes files into that directory. If the ownership changes so that apache in this example loses g+w before writing files to that directory.the installation of the plugin fails