Testing build #180

[rejetto]

Automatic update for this beta will be enabled tomorrow.

download @ www.dovedove.it/hfs/hfs180.exe

what's new
+ Menu -> Other options -> "Prevent system standby on network activity" www.rejetto.com/forum/?topic=5694
+ per-folder default sorting http://www.rejetto.com/forum/index.php?topic=5656.msg1033337#msg1033337
* new template macros syntax (automatically converted)
* re-enabled macros in diff templates, added a warning at loading
- diff templates broken in build #178 (again)
- some problems automatic updates
- {{delete}} broken in build #179
- warning shown also when removing restriction from links www.rejetto.com/forum/?topic=5603

[bacter]

Hi Rejetto

Could you please tell me what i must change to get working in #180 what worked fine in #178

[special:begin]
{{load|bts_init.tpl}}     {{comment| global vars, origin of request,browserlang(+selectedlang)->userlang}}
{{load|btslang_{{^userlang}}.tpl|special:strings}}
[special:strings]
lfile=Languagefile in template
lfmodif=20080128
th_tit=ERROR LOADING LANGUAGE

Some example code from bts_init.tpl ....

{{set|accmode|
am0=Access from wan
am1=lan access
am2=localhost
am3=wlan access
/set}}
{{comment|-------------------------------------------------------
      local: get origin of pagerequest
      0:wan 1:lan(all) 2:localhost 3:wlan(public open address-pool)
      ---------------------------------------------------------}}
{{if|{{match address|192.168.1.2-192.168.1.255|%ip%}}|{{\{{set|local|1}}/}}}}
{{if|{{or|{{match address|127.0.0.1|%ip%}}|{{match address|192.168.1.2|%ip%}}}}|{{\{{set|local|2}}/}}}}
{{if|{{match address|192.168.1.30-192.168.1.39|%ip%}}|{{\{{set|local|3}}/}}}}
{{comment|-------------------------------------------------------
      userlang: get user language in form of two lowercase letters
      blang: get browser-language from header,force if needed to supported default (xx -> en)
      if cookie exists, get user-language parameter (..lang:xx..)
      ---------------------------------------------------------}}   
{{set|language|
llist=xxesenfrdeit
lname1=Español
lname2=English
lname3=Français
lname4=Deutsch
lname5=Italiano   
/set}}   
{{set|blang|{{cut|1|2|{{header|Accept-Language}}}}}}
{{if |{{{{cut|1|2|{{substring|{{^blang}}||{{from table|language|llist}}}}}}=xx}}|{{\{{set|blang|en}}/}}}}
{{if|{{header|Cookie}}|{{set|userlang|{{cut|8|2|{{substring|lang%3A||{{header|Cookie}}}}}}}}|{{\{{set|userlang|{{^blang}}}}/}}}}

Thank you

[TSG]

I don't think a loaded file can contain macros, can you try it without loading bts_init.tpl?

I am repairing RAWR-Template and its Shoutbox hfs.diff.tpl for release.

[TCube]

Merci Rejetto
TCube





p. s : don't want to be pushy  that's why it's only a p.s 
[feature] "upload fails if there's more than X megabytes in this folder". (i.e security)
[feature] "option to display counter for folders as number of accesses instead of total access to files in it" (i.e image gallery)
[feature] "keeping the date of the last "access" to a file/folder" (i.e links)

[rejetto]

Could you please tell me what i must change to get working in #180 what worked fine in #178
{{load|bts_init.tpl}}     {{comment| global vars, origin of request,browserlang(+selectedlang)->userlang}}

first, you should convert all macro files by entering them in the template editor and clicking ok.
when you reopen it you'll find the text converted.

second, {.dequote|{.load|bts_init.tpl.}.}
But this won't work on yours because it contains macro quoting {{\ /}} and this is not supported on external files (security matters).
i guess this problem won't apply to your "btslang_{{^userlang}}.tpl"

what i can eventually do for you, is to exclude the hfs.exe folder from this protection.

[bacter]

Thanks rejetto for your reply.

It would be very interesting to have a way to {load} files containing macros from the secure hfs.exe (i call it sys) folder, as the template i'm working with is not a standalone-template, but some kind of flexible template-building-kit, that should allow including or not different features by the templatebuilder. So, instead of having one big template there is a number of alternative include-files.

As all this files will be in te secure sys-folder, i see no way to compromise the security of hfs with this option. Also, as you don't allow upload of or renaming of .tpl files there could be an additional security allowing macro execution only form .tpl files

The feature is also especialy interesting while developping: i can include debug sections, and what is very time efficient, is having sections under constructions (and loaded) in the notepad++, this means there is no need to return to the hfseditor to import and apply: simply reloading the page uses the modified code from notepad++.

Also this feature allows hfs to be used as a toolkit, for example for the admin-user to build html-tables from .csv (comma separated values) files. If features like that and many others only are included if a special condition is met, this allows to maintain the main .tpl file in a reasonable size.


Resuming: For my work there is a need to load files with executable macros from the secure sys folder. I see two possible secure solutions for this:

a) if {.load...} loads a file (check that ther is only a filename and no full path) from the secure sys folder, allow macro execution as this code where simply included in that place.
b) create a {.sload|filename.} (alt. names: sysload, include...)  macro to achieve this special behaviour accepting only filenames without path, using the path of hfs.exe.

I am using now this feature with build #178, and it works really great.

Thanks

bacter

[MarkV]

rejetto,

Autoupdate still broken. #179->#180

START "" /WAIT "C:\Program Files\HFS\hfs.exe" -q
ping 127.0.0.1 -n 3 -w 1000> nul
MOVE "C:\Program Files\HFS\hfs.exe" "C:\Program Files\HFS\hfs.old.exe"
DEL "C:\Program Files\HFS\hfs.exe"
MOVE "" "C:\Program Files\HFS\hfs.exe"
START "" "C:\Program Files\HFS\hfs.exe"
DEL %0

Faulty line in red. The first filename is missing completely.

[rejetto]

i forgot to put this line in the what's new
+ Menu -> Other options -> "Prevent system standby on network activity" www.rejetto.com/forum/?topic=5694

[rejetto]

Autoupdate still broken. #179->#180

it should have been fixed in #180
we'll see

[rejetto]

Also, as you don't allow upload of or renaming of .tpl files there could be an additional security allowing macro execution only form .tpl files

only hfs.diff.tpl is forbidden, not every .tpl
and ok, it will work from the system folder.

[Unknown8063]

How is the "sys-folder" any more secure than "some-other-folder", provided "some-other-folder" is not web-accessible?  We don't even have a guarantee that the "sys-folder" isn't web-accessible!  I just don't see PHP forcing me to clump my script includes inside the same folder as php.exe.

[rejetto]

was you going to put your scripts in another non-shared folder ?

about php: normally, files uploaded, or post data, is not eval()ed or include()d, thus is safe enough.
in hfs template everything is eval()ed, and thus even a filename could contain a command if there was no protection over it, and it would be executed.

[bacter]

Unknown8063:

We don't even have a guarantee that the "sys-folder" isn't web-accessible!

You are right, nobody forces the administrator of hfs not to share the folder where are the .ini and  .vfs files and the main template. But this is not a security problem of hfs.

Windows is not a lousy and insecure OS because some admin activates in his network settings 'client for microsoft network', shares drive C and then sets the password of the administrator account to 'admin'! This is allowed, also it's not very clever.

So we can assume that a half-baked admin of hfs would not share this 'sys' folder that contains hfs settings, user-accounts and filesystem, and therefore we can consider it as a save place.

[rejetto]

sharing the sys folder may expose the ini file, and thus the passwords.
not clever.

[Unknown8063]

was you going to put your scripts in another non-shared folder ?

I previously placed each template in a sub folder so I could preserve my customizations to each and easily swamp between them.  However, I don't really do this anymore and TSG added the only customization I needed for his template

about php: normally, files uploaded, or post data, is not eval()ed or include()d, thus is safe enough.
in hfs template everything is eval()ed, and thus even a filename could contain a command if there was no protection over it, and it would be executed.

I thought we needed a load macro in the existing template for the contents of an upload to be executed?  Unless of course someone takes advantage of the way diff templating works in real folders (wasn't there a default mask done to prevent this?)

Unknown8063:

We don't even have a guarantee that the "sys-folder" isn't web-accessible!

You are right, nobody forces the administrator of hfs not to share the folder where are the .ini and  .vfs files and the main template. But this is not a security problem of hfs.

This was the point I was making.  If the fear is that included files can be viewed/modified by users - then this isn't a concern of HFS because even the folder HFS.exe sits in could potentially fall victim to this.

Windows is not a lousy and insecure OS because some admin activates in his network settings 'client for microsoft network', shares drive C and then sets the password of the administrator account to 'admin'! This is allowed, also it's not very clever.

Oh it's worse.  Many people simply use a blank password (also allowed).

So we can assume that a half-baked admin of hfs would not share this 'sys' folder that contains hfs settings, user-accounts and filesystem, and therefore we can consider it as a save place.

But wouldn't a user who would allow upload access to their template folder be just as likely as allowing access to the HFS root folder?  I don't see what we accomplished other than an arbitrary rule.

[rejetto]

I thought we needed a load macro in the existing template for the contents of an upload to be executed?  Unless of course someone takes advantage of the way diff templating works in real folders (wasn't there a default mask done to prevent this?)

to execute the content of an upload is interesting as risky. an admin who really wants to be able to upload files load-able in the template by making an upload folder that automatically moves the file to the sys folder, with a diff template like
[upload-success] {.rename|%item-resource%|C:\hfs\{.filename|%item-resource%.}

you can't upload a diff tpl. doesn't depend on the mask.
you can't upload index.html, and this relies on the default mask.

this shows the will of the user to get such result, and hardly will cause any trouble to an unconscious user (excluding possible bugs&flaws)

But wouldn't a user who would allow upload access to their template folder be just as likely as allowing access to the HFS root folder?  I don't see what we accomplished other than an arbitrary rule.

the template folder is often exposed because it may contain resources like images and stuff.