Yannis,

I think too it's a good idea, but :

1) I haven't any compiler

2) I think it's not a good idea to give the complete acces to the whole K-Meleon directories. We'll need just to 'open' Profiles folder.

For other specific folders like tools, or extensions, it's the job of the extension installer to open it.

I know what you're going to say : kmext uses 7z and not a setup, and it won't then be possible to install kext extensions in these folders. I think that for these purposes, the kext manager ought to be installed by a setup like KMES extensions, to open the folders it needs to open.

Just a point I see there is a long time about your use of macros folder. You ought not to put ini files or other files else than kmm files.

And to be complete, don't you think there is a security problem to open macros folder, by this way, a virus could be able to put a blasted macro in the folder ?

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

Quote
JujuLand
Yannis,

I think too it's a good idea, but :

1) I haven't any compiler

2) I think it's not a good idea to give the complete acces to the whole K-Meleon directories. We'll need just to 'open' Profiles folder.

For other specific folders like tools, or extensions, it's the job of the extension installer to open it.

I know what you're going to say : kmext uses 7z and not a setup, and it won't then be possible to install kext extensions in these folders. I think that for these purposes, the kext manager ought to be installed by a setup like KMES extensions, to open the folders it needs to open.

Just a point I see there is a long time about your use of macros folder. You ought not to put ini files or other files else than kmm files.

And to be complete, don't you think there is a security problem to open macros folder, by this way, a virus could be able to put a blasted macro in the folder ?

A+

it's not just about installing 7z extensions but part of the extension manager is the ability to easily edit the associated macros without having to browse to the macros folder.. kmeleon's essence is giving customising powers to the enduser in every possible way..whether the macros or skins toolbars or accel files etc and all those are in kmeleon's root folder which is normally the programfiles by default installation.. keeping that folder locked prevents all the normal customising features of kmeleon, the user is no longer able to change menu names or order or toolbars etc so kmeleon becomes the browser you can no longer control when its folder is restricted.

i don't think the macros can be used maliciously in kmeleon especially after 1.5.3 which be default runs in limited accessibilty and macros cannot execute any system commands like acpi events and the most it can run from the system is notepad.exe.. and macros in general cannot access system core files or commands unless kmeleon was deliberately launch with the norestrict parameter. online installing is quite secured because the manager will only install 7z from kmext and not from any other website and that's pretty much under control.

only the macros kmm files are saved in the macros directory..the uninstall ini has its own folder and autoscripts that rely on an ini have those saved in the scriptdir..normally tools(except for weatherman). i personally prefer the 7z format over the installable binary for 2 reasons.. most kmeleon users prefer being able to extract the extensions directly without the manager or an install routine and the second reason so because some extensions are pretty small.. 100 kb or less..especially those based on macros only or small chrome..can sometimes be no more than 10kb..converting them into binaries increases their size and the tiniest extension grows to 300-500kb.

the problem in vista/7 is not exclusive to kmeleon but many other programs that don't necessarily use appdata or registry for settings but use the installation root to save an ini o cfg..so normally they allow write access to their folders on installation, otherwise they won't be able to save settings and that's mainly the 'vista ready' logo on some software which had to be updated to enable write to their folders.

vista and 7 are not like xp or 2k, by default xp does not restrict the program files folder but an administrator can restrict them to other users(guests) while the administrator still reserves his rights and unless an administrator specifically locks program files to users..programfiles has write access and only windows and system32 are locked by default. in vista and 7 program files is treated like system32 and even the administrator has no write unless he grants rights..ms has gone a little bit crazy

i think the best way to end this problem is by granting full write access to kmeleon folder on installation even with profiles set in appdata because kmeleon's aim is to allow users to customise and explore so it's not just profile settings and prefs.js but macro editing, toolbars and menu icons editing and all those are in kmeleon's root.

I very strongly support more user rights too, and had no idea those can be set by an installer - great news for me
But frankly am surprised about this:

Quote
disrupted
i don't think the macros can be used maliciously in kmeleon especially after 1.5.3 which be default runs in limited accessibilty and macros cannot execute any system commands like acpi events and the most it can run from the system is notepad.exe.. and macros in general cannot access system core files or commands unless kmeleon was deliberately launch with the norestrict parameter.

Just checked on my VISTA notebook which still has all those unbearable UAC restrictions and isn't really usable, only there to ruin my nerves. And switched to a "normal" user account for checking. Is it only because my KM (portable with profiles inside) is in another folder, not in the default programs folder, that customizing skins seems to work, but also starting all sorts of programs with a macro works? Frankly that seems highly risky to me, a macro can seem to start all sorts of dos commands and js commands, and start other tools like FSCapture for screenshots. But malicious tools could also be included in a extension of course, although not really needed, thinking of dos...
Frankly that's one of the reasons why I still *greatly* prefer zips for installing, I can first unzip them and examine the contents, to figure out exactly what files it's installing before really doing so :cool: Am always very uneasy with setups and if finding no workaround (if 7z can't unzip the 'setup'), often rather drop the whole thing and look instead for other tools.

I think the user should have a chance to decide himself how many writing rights to grant, first at installation, and later have an option to switch again, with the help of a menu entry. And it should come with enough explanations, so he need not be a vista/7 specialist to know what that means.



Edited 3 time(s). Last edit at 03/26/2010 11:03AM by siria.

Siria,

You say one thing and it's contrary ...

You say that macros can run cmd files for example and run dos command which can be dangerous, what I agree, and that why I think macro folder must not to be opened, and use setup system to install it

You say too that you prefer use zip files to previously look for inocuity of the extension you install, what I agree also, but to be then able to install it in the folder, you must have rights, and open the folder.

When you open the folder, you then facilitate a virus to put vicious macros which can run malicious code in OnInit() function. As a macro, when found by K-Meleon is abled by default, the code will then be executed before you can disable it, and the malicious code can alter your computer before you can do something.

That's why I say that open macro folder is not a good idea.

That's also because you want to be more prudent and in the same time you open your folder to possible problems, that I say you say all and it's contrary.

A+

---

Mozilla/5.0 (x11; U; Linux x86_64; fr-FR; rv:38.0) Gecko/20100101 Ubuntu/12.04 K-Meleon/76.0

---

Web: http://jujuland.pagesperso-orange.fr/
Mail : alain [dot] aupeix [at] wanadoo [dot] fr

---

Ubuntu 12.04 - Gramps 3.4.9 - Harbour 3.2.0 - Hwgui 2.20-3 - K-Meleon 76.0 rc

---

Really I know hardly anyhing about all those complicated rights systems, but of course it's a dilemma:
On one hand one can forget about customizing if there are no rights (=forget about most core advantages of KM), on the other hand opening all rights is dangerous!
And am not sure how skins can be customized, if there aren't any writing rights? Suppose at least the skin folder should be 'open', and perhaps some others, like default prefs, styles (macro created and -changed too)...

For myself it works fine to have the rights open (win98 for daily use), but to always first examine closely the stuff I download and put into my system.

The only way out I can think of at the moment is that the user must have the freedom to decide himself, and better yet, to be able to switch at any time. Mainly to open the rights while doing changes, then closing rights again for surfing. Or some such... ;-)



Edited 1 time(s). Last edit at 03/26/2010 01:51PM by siria.

running dos commands does not account for a vulnerability. without the norestrict command, the macro will not execute commands that may compromise the machine like formatting etc..those are system core commands.

siria, a macro can never be a security risk like that because it's static and not dymanic like js. once a macro is installed it doesn't matter if the folder is locked or not because macros can never be modified externally by a website to change its functions. meaning if a macro is malicious it doesn't matter if the folder is locked or not because the user will open the macro folder and copy that macro.. so it is installed with permissions and then it runs its code when kmeleon is launched but the macro can not be changed by a website to add a payload..this is impossible.

so the only time a macro file can be a comprise is when its first installed and not after..due to the nature of kmeleon a macro can only be installed with user's consent and knowledge so whether the macro folder is locked or not it doesn't matter because the user will allow permissions even temporarily for that folder when installing.

so granting permissions temporarily or per user choice doesn't make any difference because the macro if malicious can only be a risk at the first time its installed. once installed it doesn't matter any more if the folder is restricted or not.

so the question isn't is the macro folder better restricted or allowed..the question is : can a macro file be compromised or modified remotely after it has been installed? the answer is no.. the macro can only be modified locally by the user so the macro folder allowed access or restricted doesn't make any difference in kmeleon's security.

this problem does not just affect kmeleon extensions or macros per se..even a chrome jar can carry a pay load.. that's why you find firefox prompting a warning when you install an xpi from an unknown or trusted site but it doesn't prevent the user..it warns because many firefox xpi are fine but are not certified or not hosted on amo. this is not really a problem for kmeleon because how many sites have kmeleon extensions or macros? and to be realistic.. what malicious coder will target kmeleon and a hacker's goal is not to destroy a machine but is to steal your money or accounts or use your machine as bot.. this means that his target is to exploit vulnerabilities in the gecko which affects other browsers not just kmeleon..this makes more sense and vulnerabilities in the engine is mostly mozilla's problem and many of them don't affect kmeleon anyhow due to some services removed from the trunk.

there's no dilemma, removing restrictions from the kmeleon folder(bot not the %programfiles% altogether) will not compromise the machine or kmeleon or put the user at risk. on the other hand, keeping those restrictions means only few things in kmeleon can be customised at any time. that leaves kmeleon with very few customising abilities..nothing more than moving your toolbars around(prefs.js related only). this renders kmeleon as any other browser like firefox or internet explorer with the user's customising powers reduced to wysiwyg



Edited 1 time(s). Last edit at 03/26/2010 03:05PM by disrupted.

final note: for many years now, kmeleon has been running on machines with full write access to its installation folder..whether nt based or 9x before windows vista/7. has anyone heard of a single instance where kmeleon has been compromised due to its macros?

Am in a hurry so just quick in passing:
I do see the dangers of macros/extensions in the installation already. It may be true that KM is not yet popular enough or not interesting enough for more intelligent bad guys, but frankly, every kid can do it, and there are tons of evil idiots out there. And the first one could already badly damage the whole project. Just imagine anyone uploading a malicious macro to the wiki (maybe with an external download link, or just plain certain dos commands in the displayed kmm text to copy, that most users won't notice), shortly after a clueless user installs it and - BANG...
But fully agree that it must be possible to customize at least skins!

Quote
siria
Am in a hurry so just quick in passing:
I do see the dangers of macros/extensions in the installation already. It may be true that KM is not yet popular enough or not interesting enough for more intelligent bad guys, but frankly, every kid can do it, and there are tons of evil idiots out there. And the first one could already badly damage the whole project. Just imagine anyone uploading a malicious macro to the wiki (maybe with an external download link, or just plain certain dos commands in the displayed kmm text to copy, that most users won't notice), shortly after a clueless user installs it and - BANG...
But fully agree that it must be possible to customize at least skins!

no no no, it's not like that..this can never happen. macros are text files.. kmeleon does not have a special mime association for kmm files. in other words..they are not like xpi service and firefox where clicking an xpi link executes a remote installation.. a macro link with a kmm extension in kmeleon will merely trigger a save or download prompt like an other file. the only way a macro will be saved in the macros folder is with consent, the user will choose to save that file and this is not the case in the macros wiki regardless of km popularity.. the wiki displays the macro and the user copies it to a manually created kmm..then saves it to the macros folder so even if that folder any folder in kmeleon is restricted, the user will have to allow access first so we go back again to the first question:

can a macro pose a security risk if its folder is granted access?
the answer is no.

for a macro to pose a security risk those conditions must be met:
1- a macro can be installed online without permissions or user consent or in the background
2- a macro can instantly carry a payload once it has been installed
3- a macro can be modified or replaced with malicious code remotely by scripts on a website
4- a macro has to be a dynamic file, meaning kmeleon can accept realtime modifying on a kmm file and apply the changes instantly

those 4 conditions are impossible and can never be met unless the code of both kmeleon and the macro engine are changed to allow it9i.e. dorian and kko makes changes to accommodate such features like xpi service)

the bottom line is, security-wise; it doesn't make any difference whatsoever whether the kmeleon root folder is restricted or not

if keeping the folder locked didn't affect how a user can customise and essentially how kmeleon functions, then it wouldn't matter.. like for example a browser like firefox, where all it's editable files, chrome.css and its extensions are all saved in the profile.

but in kmeleon many editable files are in the root..almost all of them so it's not just skins.. kmeleon has menu entries to access all its cfgs..menus, icons, accels, commands..all of them are accessible from within kmeleon, if keeping the folder locked or restricted then what's the point of those entries? the user is not allowed to edit them and they just become for show..look you change accels or toolsbars with those files, but sorry..you can not edit them..you can only view them??

let's not get paranoid like microsoft, in every piece of software as simple as a notepad there can be a security risk if the user doesn't know what they are doing.. let's not turn kmeleon into a nanny browser and even that won't be true..it will be just restricting kmeleon without any security advantages and no one wants to see users coming in complaining about not being able to follow the documentation in customising and the problem will always be the restricted rights.. we 've already seen the beginning of that with settings not saved on vista and 7 with single user installation.

Oops, that was a little misunderstanding, sorry, I actually meant the possibility of malicious macros that the user deliberately installed himself, because he has no clue whether or not they are okay. Who reads every line of code and understands it?? The only trick is to get him to install it. And basically, once they are in the macros folder, they are like little programs of their own, and could be written in a way to start automatically at some event.

But you have a very good point, IF they are malicious, the damage is already done if the user has put it in the folder, they can run now regardless whether the folder is write-protected or not...

Quote

the bottom line is, security-wise; it doesn't make any difference whatsoever whether the kmeleon root folder is restricted or not

That would be great, but makes me wonder, if it's so easy, what's the point of all those vista/7 protections at all...? Cannot tell because I really know hardly anything about how all those security systems work, or what exactly javascript can do. Only keep reading that most malware from websites have as requirement that js must be enabled in a browser, so I don't trust that in the least. And somehow they manage to sneak malcode in. And that can't happen in any way with KM...?

Yes it would be pretty useless, a KM without customizations in root folder :-/



Edited 1 time(s). Last edit at 03/26/2010 11:33PM by siria.

i'm not entirely sure siria but i think the reason or the main one for giving protection to programfiles like system32 in vista and 7 etc is anti virus programs because some viruses, first thing they do is look for antiviruses resident exe and corrupt them and ddisable them by adding null values in the header of the exe so giving the entire programfiles write-restrictions can sometimes prevent viruses from attacking the av binaries but newer more sophisticated viruses can still override that or like rootkit viruses that don't care about that anyway and can infect.. however ms knowing that some programs that need full write and install in programfiles can still allow their folders write-access with installers like installshield or msi whilst keep the programfiles folder protected in general

the problem with antiviruses is they will always be a step behind viruses with the update definitions.. someone will probably bite me head off now but i don't like antiviruses and never used them.. i think the whole concept is stupid, just like artillery in a war.. one army creates what they think the best defense system which is impenetrable, soon the other army creates a superior assault weapon that completely breaks that defense..it's endless warfare and unfortunately the battlefield is your computer.

that's why i prefer simple but very efficient protection like trust-no-exe from beyond logic or ms own dep.. this way the pc is always secure and my resources are not a part of this war

How about a message that pops up when you start the macro install routine. The message would say something like "Run Anti-Virus Program before installing."

N

I think no antivirus can detect a virus in a K-Meleon macro, is more I think no virus can exist in a KM macro file because this is a text file.
It's true that you can do a KM macro file with destructive instructions like in all others script languages, but this is uncontrollable.
We only can trust the macros in Forum, Macro Library and in Extension pages.
If you download out of this sites you must sure the developer of macro is trust.

I don't think any virus want to use a KM macro file to damage a system, if any virus can damage without KM macro help.

K-Meleon in Spanish



Edited 2 time(s). Last edit at 03/28/2010 10:33PM by desga2.

Quote
desga2
I think no antivirus can detect a virus in a K-Meleon macro, is more I think no virus can exist in a KM macro file because this is a text file.
It's true that you can do a KM macro file with destructive instructions like in all others script languages, but this is uncontrollable.
We only can trust the macros in Forum, Macro Library and in Extension pages.
If you download out of this sites you must sure the developer of macro is trust.

I don't think any virus want to use a KM macro file to damage a system, if any virus can damage without KM macro help.

desga2,

Good point.

N

I'm not that sure, Desga2.

If you download the EICAR virus test file in a .txt, most antivirus will find it.

But anyway, if they don't detect it at once, they will most probably detect it when a full scan is started. The only problem about that is the extension of the macros file, because some antivirus only checks for .exe, .com and this kind of files.

This could be a problem except for the fact that, most surely, when the virus activates itself and starts messing around with the system files, making changes to the registry, sending files by e-mail, etc. it will turn on every alarm on the antivirus heuristic detection system.

Quote
enaitzjga
If you download the EICAR virus test file in a .txt, most antivirus will find it.

They will find it because of the included signature. It's a harmless test to show if signature detection of an AV works.
As desga2 mentioned a text file is harmless. It remains harmless no matter what extension you will append to a text file.

Quote
enaitzjga
If you download the EICAR virus test file in a .txt, most antivirus will find it.

Quote
EICAR.com
The file is a legitimate DOS program, and produces sensible results when run (it prints the message "EICAR-STANDARD-ANTIVIRUS-TEST-FILE!").

EICAR file is distributed like a text file (.txt) but really is an .exe or .com file renamed.

K-Meleon in Spanish



Edited 1 time(s). Last edit at 03/30/2010 07:55PM by desga2.