Warning: HFS v2.x has a severe vulnerability

[LeoNeeson]

Hi everyone! This is a notice to all the users of HFS version 2.x (I will call it 'HFS2' for making it short). Recently, a severe vulnerability (CVE-2024-23692) was found in HFS2 (known to affect HFS v2.4.0 RC7 and HFS v2.3m). This information was kept private until now, to give it time to find a solution, but now I think it's time to make this notice public. This is only an informational message to let everyone know about this. Anyone with Pascal/Delphi knowledge could contribute to finding a fix.

We are discussing how to patch it, here:
https://github.com/drapid/hfs/issues/3

You could contribute by submitting code fixes to the source code, either on GitHub or here in the appropriate forum section: Programmers corner (opening a new thread there or leaving a comment here on this very same thread). If we find a correct fix (and since Rejetto will not update HFS2 anymore), perhaps we can build an unofficial "community" version for those who can't upgrade to HFS3.

Let's keep HFS v2.x alive, and...
...please do not panic.

Stay safe,
Leo.-

[LeoNeeson]

After spending several hours on last weekend, I'm happy to finally announce that I've come up with a simple (one line) solution to this macro vulnerability.

The following is a portion of 'main.pas' in 'hfs2.3m.src.zip'
Add the line marked in red, after line 5100 in 'main.pas'
(After line 5445 in v2.4 RC07, but is hasn't been tested)

  url:=conn.request.url; // The next line is a fix for CVE-2024-23692
  if anyMacroMarkerIn(url) then url:=encodeURL(xtpl(url,['%','#']));
  extractParams();
  url:=decodeURL(url);

This was my second 'impossible task' achieved or accomplished here (the first was helping to bring the 'logout' function to HFS), and now an attempt to fix this vulnerability. Those are the good things about programming: almost nothing is impossible with a lot of effort and dedication.

[rejetto]

that's great, congratulations with your achievement, Leo!
i cannot say anything about effectiveness of this fix, but i'm happy if you can find a solution.
Is the url the only way to use the vulnerability? Even if the POC of the CVE uses the url, be sure to consider the possibility of the attack coming from a header.
you prefer 2.3 over 2.4 ?

[LeoNeeson]

that's great, congratulations with your achievement, Leo!

Thanks, it means a lot that you like it, I appreciate it. To me, it's like an exercise to dip my toes on Delphi, although there is still a long way to go...

you prefer 2.3 over 2.4 ?

Not really, some parts of it only (2.4 has huge improvements), but mainly I'm using 2.3 in my tests because it is much easier for me to build it (using TD2006). And since it was the latest stable version published, it was the version I've used it as example.

Is the url the only way to use the vulnerability? Even if the POC of the CVE uses the url, be sure to consider the possibility of the attack coming from a header.

Yes, I know what you mean ('Host' header is not covered, for example), that's why I'm not completely happy with my 'single line' fix (although it works). That's why I'm testing a completely new fix (instead the previous code). See...


» Alternative method to stop this macro vulnerability:
Add the line marked in green, after line 5084 in 'main.pas' (v2.3m)

  runEventScript('pre-filter-request');

  // Check macro leaks, prevent hack attempts
  if anyMacroMarkerIn(conn.request.full) then
  begin
    data.disconnectReason:='Hack attempt blocked. This event has been logged!';
    add2log('Hack attempt blocked: '+ansiToUTF8(conn.request.url));
    getPage('deny', data);
    conn.reply.mode:=HRM_BAD_REQUEST;
    exit;
  end;

It works, but even then, it's just a simple check and stop, not a true 'urlvar' filtering (and I can't be 100% sure if it is enough or if some hacker could think a workaround to bypass this measure). And if the browser asks for the 'favicon.ico' along with the same request, it gets logged as hack attempt too (and I don't like this, and I have to think how to handle it, perhaps with 'urlCmd'). Alternatively, I was thinking of doing a 'stringReplace' of macro markers on 'request.full' at an earlier stage, right on the 'handleHeaderData' procedure (which also works, as second measure), but I don't like this approach, since it could mess with other parts of the code.

Well, I think that's all I will be working with this at the moment, I don't have too much time to go deeper analyzing this, it's only a start for now.

[Mars]

Hello to both of you, even if I am not involved in HFS3 which for me represents a completely different project from HFS2.x, I keep an eye on the possible changes to be made to the latter.

With some similar approaches I did not arrive at a satisfactory result, there are indeed not only the urlvars to control but also the recursion of the attack used by using %url%, it is also necessary to take into account the postvars and as said rejecto the attacks by headers

I looked into a more restrictive use of the EXE macro, by limiting the programs to launch to those contained exclusively in a subdirectory of HFS, but I do not manage the %url% in the state in loop

  procedure exec_();
  var
    s: string;
    code: cardinal;
  begin

  if not fileExists(exepath+'exec\'+extractFileName(macroDequote(p))) then
    begin
      pars.clear();
      result:='';
      mainfrm.add2log('DISCONNECTED'+CRLF+exepath+'exec\'+extractFileName(macroDequote(p)));
      disconnect();
      exit;
    end;

  s:=macroDequote(par(1));
  if fileOrDirExists(s) then
    s:=quoteIfAnyChar(' ', s)
  else
    if unnamedPars < 2 then
      s:='';
  if parExist(['out']) or parExist(['timeout']) or parExist(['exit code']) then
    try
      spaceIf(captureExec(macroDequote(p)+nonEmptyConcat(' ', s), s, code, parF('timeout',2)));
      try setVar(parEx('exit code'), intToStr(code)) except end;
      setVar(parEx('out'), s);
    except end
  else
    spaceIf(exec(macroDequote(p), s))
  end; // exec_

put the file calc.exe (to test) inside a new exec\ subdir and use macro {.exec|calc.exe.} ,  bad syntax without extension  {.exec|calc.} is stopped

This is a safe and absolute start for those who do not leave an executable in the exec\ directory.

What a hacker doesn't know about available resources is an obstacle to hacking.

[sergio]

Hi.

I don't know anything about security, nor about the C language.
But if hfs is under cloudflare, does the vulnerability continue?

[LeoNeeson]

But if hfs is under cloudflare, does the vulnerability continue?

Yes, the vulnerability continues, and it could put at risk the PC (server) where HFS2 (v2.x) runs. Running it under Cloudflare somewhat makes the server more hidden (harder to be scanned by hackers), but once it's discovered and targeted by a hacker, he could run or install any program (malware or anything). Unless you run HFS2 on a VPS (or somewhere you don't have anything valuable), and you can recover your data in case of problems, you should think on updating to HFS3 (or take the risk and wait until we release an unofficial version of HFS2 with this vulnerability fixed). We are closer to find a solution to this, but the decision of waiting or updating is yours. Keep in mind that HFS3 is a completely different software (written from scratch) and its configuration is not compatible with HFS2, so you should have to configure everything again, but HFS3 is the currently recommended choice. If you have any questions about HFS3, please ask on the place dedicated to it (here), to avoid this thread going off-topic.

[sergio]

Thank you very much for the clarification. I hope it can be resolved soon.

[rejetto]

I think Mars' idea of restricting "exec" is good.
It's a pity I didn't have it at the time
I don't like the idea of having a specific folder, tho. I would rather have a way to configure what commands are allowed, so that the user must manually enable them.

[Alps]

Maybe can fix this security problem with different settings or template modification or macro deactivation ?
Maybe i am wrong, but it sounds the problem is in template and search function.

In hfs /Home Right click/properties/ deactivate Browsable
It deactivate browse page, search and other. (Files can download now only with direct link)
Probably this is not a solution, but i think the profis here know it better.

Can it help ?

[LeoNeeson]

Maybe can fix this security problem with different settings or template modification or macro deactivation ?
Maybe i am wrong, but it sounds the problem is in template and search function.

In hfs /Home Right click/properties/ deactivate Browsable
It deactivate browse page, search and other. (Files can download now only with direct link)
Probably this is not a solution, but i think the profis here know it better.

Can it help ?

*** Temporary solution ***
Yes, good idea! , if you disable macros, the vulnerability will NOT happen!
But keep in mind, you will not have file list (the default template will not work)

1) Inside HFS, press F5 to switch to 'Expert mode'.
2) Go to Menu > HTML template > and uncheck 'Enable macros'.
3) It will ask you 'Do you want to cancel this action?', click in 'No'.
4) Any visitor will have this message "WARNING: this template is only to be used with HFS 2.3 (and macros enabled)", and that means you have disabled the macros, and -hopefully-, the vulnerability will NOT happen!


- Old answer (read the message above): Unfortunately, that won't stop this vulnerability (I wish it were as simple as that). The only way is to modify the program (recompiling the source code). For the moment, it is better to temporarily discontinue the use of HFS v2.x (at least until this vulnerability gets fixed, something I haven't had time to finish yet), or even better, upgrade to the new version (HFS3).

Happy Holidays to all (and happy New Year!)

[Alps]

Very thanks for reply.

ok, as you say browsable not helps with this vulnerability "setting in hfs window part "virtual file system" " /Home Right click/properties/flags deactivate Browsable"

If i switch it off, user become message.
!Forbidden
or||!This resource is not accessible.

And it not only deactivate searchbox, it also deactivate search direct link.
Example
http://0.0.0.0:80/?search=test

If i switch also macro off.
Comes also
!Forbidden
or||!This resource is not accessible.

In this case it is better switch macro off and browsable on ? (The last years browsable off was my default setting)

I have a rootserver, and hfs was a important part, of course i can not use old hfs before have a safe solution.
HFS 3 is not a solution for me.

If macro off is a really safe solution, it is perfect for me, i need only direct linking.

Is a easy way possible for test this vulnerability ?

[LeoNeeson]

@Alps: Using "deactivate Browsable" doesn't make any difference here (you can use it, but it doesn't stop this vulnerability). The only setting that stops it, is disabling macros (since the problem is there). With macros disabled, even search works fine, you only need to use a simple template that doesn't need or use macros.

For example, I've quickly modified (removing any use of macros) the 'Stripes' template, which is a template made by the user Danny for HFS v2.3 and v2.4. These modified templates I've uploaded here, works fine for basic 'file listing' operations but doesn't have the upload, delete or login function (login still works when using v2.3), but you can add those functions back, if you have the knowledge to do it, and you don't use macros (I currently don't have enough free time nor the patience to do it).

Well, that's all for now, hope it helps.

[Alps]

This sounds all great 
Maybe this is the best solution.
I am Happy can now use hfs again after 6 months break. 

In changelogs from "j" "k" "m" i not read security fixes.
versions down to 2.3i now also safe with macro off ?

in a russian forum i found also a solution including fixed hfs download
maybe it is interesting for you.
http://forum.ru-board.com/topic.cgi?forum=5&topic=13365&start=1940#11
i not know how safe it is.

Macro off is the best way for me.

[LeoNeeson]

versions down to 2.3i now also safe with macro off ?

With macro OFF, those versions could "probably" be safe, but I can't give you a 100% guarantee "that versions down to 2.3i are also safe with macro off" (I haven't tested it to give you confirmation). Macros were always like a 'Pandora box' for vulnerabilities, but many other enhancements were introduced since version 2.3i.

in a russian forum i found also a solution including fixed hfs download

Thanks for the link. Sadly, that 'fixed HFS' download is not safe with macro ON. The solution posted there (and that compiled executable), is not enough to stop the vulnerability (since it only search the 'exec' word in the URL, and that word can be split in two words to bypass that solution, so I don't recommend it). You could point those users to visit this forum thread, so they could get updated info about this issue.