search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

Missing checks in the locale.module #6592

Open findlabnet opened 4 months ago

findlabnet commented 4 months ago

Description of the bug

Today I've seen possible attempts to exploit CVE-2024-4577 on some sites.

From Apache log:

"GET /index.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 301 606 "
-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
"GET /index.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 200 37363
 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
"GET /test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 301 604 "-
" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Then dblog events:

Notice: Trying to get property 'direction' of non-object in locale_library_info_alter() (line 825 of /.../core/modules/locale/locale.module).

Notice: Trying to get property 'langcode' of non-object in locale_js_alter() (line 783 of /.../core/modules/locale/locale.module).

Notice: Trying to get property 'langcode' of non-object in locale_js_alter() (line 800 of /.../core/modules/locale/locale.module).

The above functions use the global $language object without checking for its existence / initialization.

Should such a check be added?

Additional information

Add any other information that could help, such as:

indigoxela commented 3 months ago

@findlabnet interesting, but a little hard to reproduce without Windows (which I don't have). Is there any other way to trigger such a notice in locale? I wasn't able to.

The above functions use the global $language object without checking for its existence / initialization.

The $language global gets initialized in backdrop_bootstrap() in step BACKDROP_BOOTSTRAP_LANGUAGE, which happens before the full boostrap is done - that's quite early.

I'd assume that any later function can safely rely on the existence of $language and shouldn't have to do extra checks.

There might be edge cases though, where backdrop_language_initialize() didn't run, yet. Hard to know without steps to reproduce.

findlabnet commented 3 months ago

I do not have Windows too and there is no direct relation with, just logged cracking attempts.

indigoxela commented 3 months ago

I do not have Windows too and there is no direct relation...

Ah, OK, but you did see this Notice: Trying to get property... nagging. So this should (somehow) be reproducible. But how? Calling the posted URLs doesn't seem to be sufficient (tried with wget and curl).

findlabnet commented 3 months ago

It may not have been related to CVE, but I saw such attempts more than once after that. I have not tried to reproduce it myself.

avpaderno commented 3 months ago

I tried on a preview site for a PR. Only the last URL logs (and shows) a Page not found error; the first two just redirect me to the front page.

That is different from what the quoted Apache log shows (a redirect for the first and third URLs).

findlabnet commented 3 months ago

Start part of URL used by attacker can be not only /index.php?%ADd+... but also /test.php?%ADd+... and /hello.world?%ADd+...

findlabnet commented 3 months ago

If no one else has seen it, the issue can be closed.