Messages

1

Everything else / Taking a summer break and some time off

« on: January 22, 2025, 03:50:24 AM »

Hey everyone! Some of you might already know (those who contacted me via private message), but for the rest, I want to let you know that I’ll be stepping away from my computer, the forum, emails, etc. for a few weeks. It’s summer over here, and during this time (from January to about March/April), the weather allows me to do some home projects that aren’t possible at other times of the year (like painting, general cleaning, and small repairs).

I just wanted to mention this, so you could understand why it might take me a while to respond or provide detailed replies (I will probably check things once a week). It’s not due to a lack of interest or anything; it's just a little break from all the tech stuff during these hot weeks. But when summer is over, I’ll be back around more often!

Cheers,
Leo.-


PS: I'm closing this topic since it doesn't need any further comments.

2

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 10, 2025, 04:26:55 PM »

Ok, if we don't count "%item-url%" as macros, than you are right.

I agree that it looks similar, but '%item-url%' is one of the 'Symbols' available (Macros and Symbols are both processed at server-side). %Symbols% are much safer and already existed in very ancient versions (before Rejetto added macros in v2.3x), and are replaced by the real values at run-time (when the HTML page is built), meanwhile macro works like server-side scripting.

I like the idea to have a separate template for no-macros mode. So I will add an option "Disable macros for non-local IP" to use separate templates for local and non-local users.

I'm glad you like the idea.

For any other thing related about this, it's much better to open a new thread in 'Programmers corner', to not disturb users subscribed to this thread who are waiting for news on this issue.

3

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 09, 2025, 07:36:35 PM »

I think you misunderstands what macroses are.
Templates are based on macroses.
So "no macros" = "no templates".

By saying 'templates are based' on macros, it could only mean 'some templates depend' on macros (but only those templates that need a macro to work, like, for example, the default template). However, your latest statement is not entirely accurate, since you can have a template without macros. Otherwise, you would not be able to install or use the templates I've modified in this post HERE, which can be used with macros disabled (obviously, some features are disabled, such as the ability to delete, rename, or upload files, but it's still a template after all). I'm not looking to argue, but I do have a clear understanding of what macros are and how they work.

For me HFS is just a Home File Server.
I don't really care about security.
All changes are just for fun...

Then, just for fun, you have given me the opportunity to say the following: "Ladies and gentlemen, we now have..."

- Option D: DRapid version of HFS! (32 bits & 64 bits)
Yeah! this version is good for those who want to use templates while avoiding this vulnerability, and also for those who, based on his own words (not mine): 'don't really care about security'. So, if you feel comfortable with this, you will find this version very interesting.

» Seriously speaking, from what I've seen by running the program and conducting some tests (and also after reviewing the patch in the source code from an older build), it seems to avoid the vulnerability. However, I don't see this as a definitive long-term solution. That being said, I can't provide ANY guarantees, and it's up to the end-user to decide whether this is appropriate to use or not.

what is missing it´s a swtich of templates as exist when we use a computer or smartphones for example, but in this case it´s more simple to have two versions of hfs and run only the one with macros or not

Even better: two HFS versions on two separate computers!

4

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 09, 2025, 12:58:25 AM »

Could you check my versions, if it vulnerable or not? As I'm not really understand your answers per my fixes.

I've sent you a private message because I can't run x64 apps.
You can use 1Fichier to upload files if that's easier for you.
Until then, I can't review your version; I'm sorry...

I really don't understand, why you afraid only 'exec' macros. With "save" macros it's possible to do the same (if write 'bat' or 'lnk' file). With 'add folder' - it's possible to add home folder of active user, and maybe download something private.

I completely agree with you (and I was already aware of all that).

it is always possible to use version 2.2f which makes it possible to distribute content as one looks at a film,

We can have the best of both worlds if we do this:

(Ideas) The best way to achieve good security would be:
• Make the default template not use or require any macros at all.
• Make the entire macro system behave exactly like user permissions.
• Have a config panel to let HFS admin choose which macros are enabled.
Even then, nobody could guarantee 100% permanent security forever...

Making all those changes will take a lot of work, time, and testing.
(but it will provide all the features without compromising security)

5

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 07, 2025, 02:40:55 AM »

Since we are joking...

@Rapid: You did it! 0 bits = 0 vulnerabilities !

@Mars: Now I do understand why your timer is set to 30 seconds...
...and also because it only takes '30 seconds to Mars'
...a nice rock band, although I prefer Bruno Mars

I'm sorry, I think I went too far today...
(too many jokes in one post)

6

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 06, 2025, 11:42:54 AM »

Good! ...and now we have:

- Option C: Mars’s version of HFS! (v2.3m Build 305)
This option is perfect for those who want to make normal use of the default template (while also wanting to programmatically run programs using HFS, but don’t want to leave this option enabled for too long). This also provides another alternative (besides 'Option A or B') for those who wish to disable the 'exec' macro feature to be more secure.

What is the difference between 'Option B' and 'Option C'? The difference is that 'Option B' disables all macros (including the less risky macros that are necessary for normal template functionality), while the Mars compilation only disables the 'exec' macro (which allows other programs to be executed, and this was exploited by this vulnerability). Since the vulnerability still exists, if you use 'Option C' (and enable the 'exec' macro), it's best to allow it only for a short period, or to disable it directly when this feature is not needed.

It’s nice to have more options for those who may need them.
Everything seems fine, and it’s good, coming from Mars (congrats!)

7

HFS ~ HTTP File Server / Temporary solution to vulnerability CVE-2024-23692

« on: January 03, 2025, 01:10:25 AM »

@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.

I correct myself (my mistake): @Alps was right on his first message (and then here), by unchecking the 'Browsable' flag on the 'Home/Root' of HFS, you could avoid this vulnerability and be safe. That seems to be enough, but if you also disable macros, you are twice protected. If you use v2.4 and need to use the login system, then don't disable macros (using v2.3 you can disable macros + uncheck browsable flag, since login system depends on the browser).


Summarizing, now we have 2 options to be safe and avoid this vulnerability:

- Option A: unchecking the 'Browsable' flag
1) Inside HFS, make sure 'You are in Expert mode' (if not switch by pressing F5)
2) In 'Virtual File System' panel, right-click on the 'Home' icon, select 'Properties...'
3) Properties window will open, go to 'Flags' tab, and uncheck 'Browsable' option.
4) Click 'OK' to apply changes, and from now on, any visitor to your HFS server, will see this message: "Forbidden / This resource is not accessible", and you will not have file listing, neither file search.

- Option B: disabling the 'macros' feature
Simply follow the steps described in this post, here.

I give all the credits for both of these methods to @Alps!

Cheers,
Leo.-

8

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 01, 2025, 11:00:55 PM »

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.

9

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: January 01, 2025, 01:22:28 PM »

@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.

10

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: December 31, 2024, 08:46:25 AM »

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!)

11

Everything else / Re: Best DynDNS alternative: FreeDNS.afraid.org

« on: October 19, 2024, 09:46:55 PM »

I wonder, can HFS update it automatically?

Yes, it's easy, but read a very important note at the end...

1. Login to your FreeDNS.Afraid.org account and go to "Dynamic DNS".

2. Copy the link from "Direct URL" for the domain you want to update.
     

3. From that link, change "https://" to "http://" (removing the 's'),
   since HFS can't handle SSL connections (unless you are using v2.4 RC7).

Link example:

Code: [Select]

http://freedns.afraid.org/dynamic/update.php?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4. In HFS, press F5 (if you are not already in 'Expert mode'), and go to...
   'Menu' > 'Dynamic DNS updater' > 'Custom...' and paste there the link.

5. It's all ready. Enjoy!


NOTE: My recommendation for FreeDNS.Afraid.org remains, but I currently do not recommend to use HFS to do the 'DNS update' (as a 'Dynamic DNS client'). It can be used along HFS, but it's better not within it. This is because, no matter what DynDNS service you do use, I've noticed that HFS it's not very reliable for this task (I've found a small bug when using the 'Custom' option, and although it seems to work, I can't guarantee it will always function). What kind of bug? HFS is -always- updating the DNS even if is not necessary, without checking first if the IP of the hostname has changed or not, and this leads to this "ERROR: Address 123.xxx.xxx.xxx has not changed." For casual use, it could work fine, but for use on as a permanent server, it's much better to use another DDNS client to update the IP.

12

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: October 09, 2024, 04:12:26 AM »

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.

13

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: October 06, 2024, 06:46:05 AM »

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.

14

HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability

« on: October 02, 2024, 06:36:55 AM »

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.

15

Everything else / Re: Message to Rejetto: forum's email is broken

« on: August 11, 2024, 12:25:15 AM »

It's still working here, and I agree that the main reason of all this problem (and also of having too many spam accounts), is the use of fake/disposable email address to register (like you said 'invalid addresses'). If we filter that registration comes ONLY from common respectable email providers, like: Gmail, Yahoo, Hotmail, Yandex, GMX, QQ, etc. then those spam accounts will be much less.

Reading a forum thread on SMF Community Forum, about "Restrict email providers on registration", I've found THIS mod, which works with current SMF version, and has a very useful option named "Only allow these providers" (along with preventing people using their email addresses as usernames).

PS: nothing is perfect, since one Gmail account could have MANY email alias (and register many accounts on the forum using those alias). So, it would be great if we could 'clean' the email username from any "+" (plus symbols) and "." (dots), when someone is using Gmail to register to avoid the 'alias' trick. Perhaps that mod that I mentioned, has this feature too (I don't know).