Fossil Forum

CVE-2022-34009
Login

CVE-2022-34009

CVE-2022-34009

(1) By anonymous on 2023-03-07 13:04:46 [source]

Is it fixed? CVE-2022-34009

When? What version?

(2) By Stephan Beal (stephan) on 2023-03-07 13:35:41 in reply to 1 [link] [source]

Is it fixed? CVE-2022-34009

It has not, to the best of my recollection, come up here before, despite the reporter's statement that:

I disclosed it to the developers and submitted a CVE assignment request!

It's certainly possible that he reported it directly to drh.

From the reporter's article:

Note that an anonymous user can create and submit this ticket.

Only if the repository administrator permits it. It has proven to be poor practice to allow anonymous users to post tickets and append comments to wiki pages because those features can be (and have been) used to automate spam injection into repositories.

(3) By jvdh (veedeehjay) on 2023-03-07 13:45:30 in reply to 2 [link] [source]

Only if the repository administrator permits it. It has proven to be poor practice to allow anonymous users to post tickets and append comments to wiki pages because those features can be (and have been) used to automate spam injection into repositories.

but that's the default setting out of the box, no? maybe the defaults should be more conservative ("off" for everything potentially problematic for nobody and anonymous? and only "reader" might get those capabilities then by default (which he currently inherits from anonymous if I get that right -- this I, too, find a bit confusing right now: if one deactivates all the stuff for anonymous one needs to manually reactivate it for "reader" it seems)

(5.1) By Stephan Beal (stephan) on 2023-03-07 14:23:39 edited from 5.0 in reply to 3 [link] [source]

but that's the default setting out of the box, no?

Apparently so.

Trivia: to the best of my knowledge, my repos were the first ever to get bot-spammed (back in 2008 or 9 or so), and disabling any sort of write access for the anonymous has been an automatic/scripted thing for me since then.

Looking over the defaults now, they're "hmnc", which is (IMO) too lenient. An argument can certainly be made for permitting anonymous users to post/update tickets, and possibly even appending to wiki pages, but IMO that should be opt-in, not the default.

i'll petition Richard to permit these to be reduced to "hz".

Edit: done. Trunk now defaults to "hz".

(4) By Richard Hipp (drh) on 2023-03-07 14:08:31 in reply to 1 [link] [source]

I've never heard of it before. Good grief. Why is this even a CVE? Why is this called as a bug in Fossil when the real cause of the problem is Windows Defender deleting files out from under a legitimate application?

Easiest fix:

Never, never, never host an internet-facing service (of any kind, Fossil or otherwise) on a Windows server. Just don't do it. There is no good reason to do it. It will almost always end in grief. Linux hosting is way cheaper, way faster, way more secure, and way easier to manage.

Fossil does provide the ability to serve content from Windows. This is intended for ad hoc and/or temporary "pop-up" servers on a private network. The windows-server code is hobbled by the inadequacies of the Windows API and is not optimized. It works well enough for its intended purpose of "pop-up" hosting and the "fossil ui" command, but its use on persistent, internet-facing sites is discouraged. If you want a persistent, unattended, internet-facing Fossil instance, you will do much better to host it on Linux or similar posix-derived platform.

(6) By Richard Hipp (drh) on 2023-03-07 14:22:40 in reply to 4 [link] [source]

So what is the preferred fix for this? Encrypt the temporary transfer files so that Windows Defender can't mess with them?

(7) By Warren Young (wyoung) on 2023-03-07 16:01:37 in reply to 6 [link] [source]

Surely it's as simple as checking return values on the calls that open and read from the files, then emit an error message into the HTML instead of the submitted content if it goes unexpectedly MIA.

I don't see where src/tkt.c makes these temporaries, giving Defender a crack to snaffle files away from Fossil. It must be in the lower-level generic parts of the code. Doesn't the CGI implementation on Windows do something like this as a workaround for lack of fork()?

(8) By Stephan Beal (stephan) on 2023-03-07 16:09:20 in reply to 7 [link] [source]

I don't see where src/tkt.c makes these temporaries,

The temp filenames in the report (fossil_server_...) can be traced to:

src:/file?ci=d9c4321e7ac26b5b&name=src/winhttp.c&ln=666-671

And that string is then used in win32_http_request() to create the files:

src:/file?ci=d9c4321e7ac26b5b&name=src/winhttp.c&ln=353-358

It's apparently not ticket-specific, that's just one way to trigger it.

(9) By Warren Young (wyoung) on 2023-03-07 16:16:20 in reply to 8 [link] [source]

That looked plausible until I traced the code further. If the file disappears within the fwrite() call on line 395 (or shortly thereafter) such that it's gone by the fopen() call after the while loop, how does it crash? It detects an error, cleans up, and returns.

(10) By Richard Hipp (drh) on 2023-03-07 17:33:30 in reply to 9 [link] [source]

I tried to simulate that error by inserting (uncommited) test code that causes the file to disappear if the request contains the string "XYZZY". That caused the web browser to complain about not getting a valid response, but the server process continued running and was able to answer subsequent requests (that did not contain the magic string) without any problems.

I think what is happening is that Windows Defender is somehow locking the file such that the fread() causes an I/O error which terminates the process. But that is only a guess.

(11) By anonymous on 2023-11-06 11:39:31 in reply to 1 [link] [source]

Does version 2.23 (2023-11-01) with the point "Improved defense-in-depth against malicious attack" fix this issue?

Fossil Changelog

(12) By Stephan Beal (stephan) on 2023-11-06 12:08:47 in reply to 11 [link] [source]

Does version 2.23 (2023-11-01) with the point "Improved defense-in-depth against malicious attack" fix this issue?

As Richard wrote above:

I think what is happening is that Windows Defender is somehow locking the file such that the fread() causes an I/O error which terminates the process. But that is only a guess.

We were never able to reproduce this problem, which appears to be a side-effect of interference from third-party software (Windows Defender), so we don't have a specific solution for it. As it only happens in a configuration which we very strongly feel should never be deployed, there's not been much interest in pursuing it. (That's my take on it, anyway.)

If you have a way to reliably reproduce it, please let us know.