K-Meleon :: Development

Development : K-Meleon Forum

K-Meleon development related discussions.

Goto: Forum List•Message List•Search•Log In

Your Name:
Subject:

Help information

[quote=disrupted]
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[/quote]

K-Meleon forum is powered by Phorum.