Leaderboard

I wonder if @ryan was ever contacted about this. I've tried to come up with a scenario where the URL injection mentioned in the CVE can become exploitable, but I'm having a hard time. When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality. That's why we have DANE, so the communication stays confidential even if you're routed through untrustworthy networks. I've sent a rejection request to MITRE with the following rationale:

Yes, exactly. Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel. It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

A new vulnerability (CVE-2023-24676) was published last week, detailing how module install can be used to execute code and set up a reverse shell on a site. After going through the post that explains the exploit a couple of times I'm wondering if someone could confirm that I've got it right: First of all it requires that a) web server has write access to the modules directory and b) ProcessWire is configured to allow file uploads, right? The latter is by default true in debug mode, which is also mentioned in aforementioned post as one of the conditions. Built-in module downloading features check the moduleInstall setting (in ProcessModuleInstall class) and I couldn't find any way to circumvent them. For anything bad to happen, user with (presumably) superuser access must type in an URL of a ZIP file with malicious code, or someone must be able to intercept the request and change it. First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them, while the second part (to my understanding) sounds like it would be very unlikely and quite difficult, at least assuming that requests are passed through HTTPS. According to the post the PHP file in the zip is automatically executed by the system. I find this part a bit strange — I'm not exactly familiar with every involved piece of code, but it doesn't seem like ProcessWire should do that. On the other hand if the file in the package was a properly formatted module class, then this would be more likely, and again probably not something that can be prevented. So, in other words, it seems to me that this vulnerability isn't really a vulnerability — more like a way to use a built-in feature to do potentially harmful actions, of which users are specifically warned about in UI of said feature? Let me know if I got something wrong here, though. If anything, it seems to me that this is a good reminder that it is indeed dangerous to enable file uploads from arbitrary URLs or allow web server to write files that could be executed as PHP (or any other language for that matter, including JavaScript). Only thing that I think we could do better is to set those module file download settings false by default, instead of debug as they are now, just to be extra sure that a developer has indeed intentionally enabled them ?

This feedback is so great, I have to share it with you ? Thx so much @FireWire and thanks for brilliant fluency module!! Just pushed v5.2 to the main branch!

I was just joking about how you wrote the "Hit CMD+Enter" like if the answer is sure, don't take my message too seriously. ? I wouldn't event trust the answer about rw-r--r--, because very often ChatGPT is absurdly wrong and answers the exact opposite of the truth. Then I correct it and next answer is good. So if I need to check the AI answers on the web, it's faster not to ask the AI and directly go on the web/documentation. Most of the time I use AI when I can't find answer with traditional ways. This part is more interesting IMO, discussing about architecture of your own code, things you can refactor, design patterns you can use... It can be a way to improve faster as a developer. I'm also working alone, and have worked in the past in a team that used to do regular code reviews.

Based on how they kept specifically mentioning the requests containing the download_zip_url variable and the relatively high score this CVE has (7.2 High) I was expecting that they'd found some major issue, or perhaps a way to circumvent normal core behaviour. But really it just seems like they figured out that if you are able to inject code into the system you can use it to do nasty things. There is one difference to the Tracy example, of course: in that case the administrator would have to install Tracy and then type in the command to the Console panel. If the attacker doesn't have superuser access but they know a system that matches aforementioned conditions, they could lure an existing superuser to install malicious code via the admin ? -- I don't want to belittle any potential security issues, but it seems that this one is blown way out of proportion. I'm not familiar with the process used to validate and score CVE's, but it seems that they definitely err on the side of "always assume that reports are true, and always assume that the issue is as bad as it could theoretically be".

FieldtypeGrapick The FieldtypeGrapick module for ProcessWire wraps the Grapick vanilla javascript gradient creation UI and extends the feature set to include settings beyond what the original library allowed for. The original javascript library was written by Artur Arseniev. Aside from requiring ProcessWire 3, the requirements are: PHP >= 7.2 or >= PHP 8.0 This module makes use of the Spectrum colorpicker library. Repeater and RepeaterMatrix items are supported. There is a gremlin in RepeaterPageArray iteration that causes warnings. I've created an issue for it. It does not impact performance. CssGradient Object The FieldtypeGrapick field value is a CssGradient object. $gradient = new CssGradient( $options=[] ); where $options is a list of properties: $options = [ 'style' => 'linear', 'stops' => 'FFFFFFFF^0|FF000000^100', 'angle' => '180', 'origin' => '', 'size' => '', ]; Properties The CssGradient style by default is linear, 180deg, with a white opaque stop at 0% and a black opaque stop at 100%. style $gradient->style: gives you the dropdown value of the style of gradient. Setting this automatically uses the correct settings for the css function and shape parameter as required. Possible values: 'linear' = Linear 'radial-circle' = Radial Circle 'radial-ellipse' = Radial Ellipse 'repeating-linear' = Repeating Linear 'repeating-radial-circle' = Repeating Circle 'repeating-radial-ellipse' = Repeating Ellipse 'conical' = Conical 'repeating-conical' = Repeating Conical Any other value defaults to linear. Depending on the type of gradient selected, origin, angle, and/or size will come into play. The stops are always used to determine the order of colors and their relative locations according to the limitations of each style. origin $gradient->origin: gives you the dropdown value of the origin of the gradient as it applies to radial and conical gradients. The format is X%_Y% if for some reason you want to set a custom X/Y origin. The dropdown values are typically what I find useful for most applications, but I am open to adding other presets. '-100%_-100%' = Far Top Left '50%_-100%' = Far Top Center '200%_-100%' = Far Top Right '-50%_-50%' = Near Top Left '50%_-50%' = Near Top Center '150%_-50%' = Near Top Right 'top_left' = Top Left 'top_center' = Top Center 'top_right' = Top Right '-100%_50%' = Far Middle Left '-50%_50%' = Near Middle Left 'center_left' = Middle Left 'center_center' = Center 'center_right' = Middle Right '150%_50%' = Near Middle Right '200%_50%' = Far Middle Right 'bottom_left' = Bottom Left 'bottom_center' = Bottom Center 'bottom_right' = Bottom Right '-50%_150%' = Near Bottom Left '50%_150%' = Near Bottom Center '150%_150%' = Near Bottom Right '-100%_200%' = Far Bottom Left '50%_200%' = Far Bottom Center '200%_200%' = Far Bottom Right angle $gradient->angle: gives you the angle in degrees of the gradient as it applies to conical and linear gradients. Should be a value between -360 and 360. Measured in degrees. size $gradient->size: gives you the size - of what depends on the type of gradient. For radial ellipse gradients, at applies a size of XX% YY% using the value. So 25 would represent a size of 25% width, 25% height of the container. For repeating linear, conical and radial gradients, the repeating gradient will apply the percentage stops as a percentage of this value. In the case of repeating linear gradients, if you have your stops at 0%, 10%, 50% and 100% and your size is 200, the stops in the calculated rule will be at 0px, 20px, 100px and 200px. For repeating ellipse and conical gradients, a similar calculation is performed, but the units are %, not px. You can get some crazy tartan backgrounds out of this if you stack your gradients up and are creative with transparencies. stops $gradient->stops: gives you the current stop settings in a AARRGGBB^%% format, with each stop separated by a '|' character on a single line. You can role your own gradient ruleset by modiying this property prior to getting the rule. When using the UI you can also reveal the Stops inputfield and change the stops manually, however you will need to save to see the changes in the UI. rule $gradient->rule: gives you the stored rule that is calculated prior to the field value being saved to the database from the UI. Of course, if you are ignoring the UI altogether and just using the class, you will probably ALWAYS want to call getRule() rather than use this property. If you render the field, it will return the rule as a string. Methods The CssGradient has a single public method that is mostly useful when manipulating an instance of the CssGradient class. getRule(string $delimiter) $gradient->getRule(): calculates the rule based on the properties or options you have set for the field. This automatically runs if you have set an $options array and populate the rule property, but if you decide later that you need to change the properties of the object, you'll want to manually call it again to recalculate it. For example, if you programmatically change the stops, you will want to run the getRule() method rather than just grab the rule property. If you pass a string, the first character will be used as an ending delimiter. If you pass an empty string, no ending delimited will appear. By default, the rule is output with a semicolon. Grapick UI The Grapick UI is relatively straightforward. Clicking the (x) handle above a gradient stop removes the stop from the gradient calculation. If you remove all the stops, the bar is transparent. Clicking on the gradient bar sets a stop conveniently set to the color you click on. Clicking on the colorpicker box below the stop line allows you to select the color and transparency of the stop. Click and drag the stop line itself to modify the gradient. Making changes to any of the controls on the field will update the preview and the calculated rule in real-time. You can always cut and paste this rule and use it in your designs elsewhere if you want. Likewise, if you open the Stops inputfield area (which is collapsed by default) you can directly alter the colors and code using a color in an AARRGGBB format and adjust the stop with a number from 0-100. It's fun to play with - experiment with hard and soft lines, size and origin - many interesting effects are possible. Do not forget that the alpha slider is also available. Examples $grk = new CssGradient($options=[ 'style' => 'linear', 'origin' => '', 'angle' => 270, 'stops' => 'FF8345E4^0|FF5A08DB^25|FF2C046B^97|FF000000^100', 'size' => '', ]); echo $grk->getRule(); will give you: linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%); while echo $grk->getRule(''); will give you linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%) and echo $grk->gerRule(','); will give you linear-gradient(270deg, rgba(131, 69, 228, 1) 0%, rgba(90, 8, 219, 1) 25%, rgba(44, 4, 107, 1) 97%, rgba(0, 0, 0, 1) 100%),

This week I was wrapping up the client project I mentioned last week (just launched today here), but did get some updates added to the core as well. Primarily the addition of some smaller feature requests. One of the features added is a README.md and CHANGELOG.md viewer to each module's configuration/info screen. When a module has one of those files in it, it is now viewable from within the admin. You'll see the links them at the bottom of the "Module information" section of any module's config/info screen in the admin. Other requested features added were: Support for OPTIONS, CONNECT and TRACE methods in WireHttp. And, A new hookable method in ImageSizerEngineIMagick added via a PR from Robin S. Support for <hr> elements has been added in InputfieldSelect and InputfieldSelectMultiple. It was news to me, but apparently <hr> (horizontal rule) elements are now supported by browsers between <option> tags in <select> elements, rendering a nice separator between options when you want them. So our Select inputfields now support that. To add a horizontal rule/separator, just add an option with 3 or more dashes/hyphens. Programmatically you would do a call like this when you are between options where you want the <hr> to appear: $inputfield->addOption('---'); Or, if specifying options as text (as you would with Options fields, or several other Fieldtypes), you would just enter a line with 3 or more dashes on it, and nothing else. So if we had an select where you could select a color, and we wanted to separate RGB from the other colors, we could do this on its configuration screen: R=Red G=Green B=Blue --- O=Orange P=Pink C=Cyan Thanks for reading and have a great weekend!

This is the part that I was most confused about. The post goes to detail about trivial stuff such as how to create a zip file, but then simply states that... They make it sound super easy, and obviously it is when you are both the attacker and the victim, but that has little to do with real world. Of course MITM is a serious threat and systems should be configured properly and users should be educated about risks of e.g. connecting via public wifis, but it's not something you can just pull off like it was nothing. And yes, any system that allows the user to directly execute code or upload files that are executed as code is technically "vulnerable" once you gain access to those features. That being said, I do see some potential for improvement here. For an example I think the default settings for moduleInstall should be as strict as possible, and I'm also wondering if ProcessWire could do light-weight scanning of obviously dangerous actions? Something like checking if an uploaded module/PHP file contains exec/eval/etc. or base64 encoded values, and at least displaying a warning to the user. Not sure if that's really feasible or particularly useful, though, and it could no doubt be circumvented by a targeted attack. Just a rough idea ?‍♂️

Hey @spoetnik, thank you for your input! I think Twack's base with its component structure could be a good foundation to fit HTMXs needs, but I am a little worried about opening security gaps. It is certainly possible to build a function that can be used to get each individual Twack component back individually. But we have to make sure that no access-protected information becomes accessible. I usually control the access authorizations on the ProcessWire page - individual components cannot be easily controlled. A good approach could be to request the page as before, but to provide a kind of identifier that ensures that only the subcomponent with this ID can generate an output from the component tree. As a result, the access rights would continue to be active as before and no output can be obtained via the HTMX request that would not already have been contained in the classic request with the output of the entire page. But I'm still not really sure whether this is the best solution for this feature.

I do like to refine some of my code in little steps or to prompt the AI for specific questions on my own code, like I did in the past as part of a development team with my human colleagues. Thats where AI is really not so bad in my opinion, at least if you are working alone on projects and there are no human colleagues you could ask.

@da²Guess Bernhard still checks the generated code for stuff which may break things like rm -rf commands before blindly copying and pasting code to clients projects or executing it blindly on his system with root permissions ?

Thanks for spotting this. Did you try this and will it return the correct field type? If so, could you please make a PR? Thank you.

Sorry for bumping an old topic. I have made a GitHub repo for my dev, and production setup. https://github.com/spoetnik/apache_php-fpm_mysql