Upgrade Accessible For All Visitors

[Blesta Addons]

i have uploaded the files 3.4 to the blesta installation , i was not logged in as admin , and i have upgraded the website as visitor .

 

the upgrade proccess should check if the user is logged as main administrator .

 

 

[Michael]

i have uploaded the files 3.4 to the blesta installation , i was not logged in as admin , and i have upgraded the website as visitor .

 

the upgrade proccess should check if the user is logged as main administrator .

 

I don't see a issue here, because:

 

1. Only the url is known to the admins unless it's the default one.

2. It helps Blesta and myself helping customers who forget and open a ticket for help.

3. It doesn't do anything unless you uploaded the new files.

[Blesta Addons]

I don't see a issue here .

 

upgrade === admin task not guest task .

 

this is the first time i see great software give the guest/visitor acces to upgrade proccess .

[Michael]

upgrade === admin task not guest task .

 

this is the first time i see great software give the guest/visitor acces to upgrade proccess .

 

But does it matter? no can they break it... no.. can they log in? no.. can they upload files? no.... what's the issue? nothing.

[Paul]

What if you're not logged in, and now you can't login because of a MySQL error?

[Blesta Addons]

What if you're not logged in, and now you can't login because of a MySQL error?

so this is a blesta code probleme , not mine . the upgrade script in all the other soft , has just a login page and next step is upgrade , you think the upgrade script should get the admin fields and profiles and other detaille from database . just make it validate the login/pass .

the login page just need 2 input and 1 hidden , and check it in the database !!!!

let imagine the worst case , the upgrade script has a security hole , the guest can send command to the database directly without to check the authorized user or not , and next day you will find your database in a dirty hands . security is a + in blesta , don't play with this point .

finallyn , if you find this is not really a probleme, close the thread as not a bug .

[Michael]

let imagine the worst case , the upgrade script has a security hole , the guest can send command to the database directly without to check the authorized user or not , and next day you will find your database in a dirty hands . security is a + in blesta , don't play with this point .

 

Blesta doesn't doesn't do holes. And again upgrade doesn't do anything unless you upload a patch... so you are just over-exaggerating over nothing. Blesta doesn't pull a WHMCS and they defiantly don't pull a hostbill with their "upgrade" script.

[Blesta Addons]

Blesta doesn't doesn't do holes. And again upgrade doesn't do anything unless you upload a patch... so you are just over-exaggerating over nothing. Blesta doesn't pull a WHMCS and they defiantly don't pull a hostbill with their "upgrade" script.

 

if a over-exaggerating now, is to avoid surprise in the future , mate .

 

keep in mind nothing is this world is 100% secure . and stop advertising blesta as other think blesta is the 1 soft ranking in this world .

 

blesta is good and is not a complete piece of art in his category, this is the reality and you should accept it woth "FAIR PLAY" spirit   .

[Michael]

if a over-exaggerating now, is to avoid surprise in the future , mate .

 

keep in mind nothing is this world is 100% secure . and stop advertising blesta as other think blesta is the 1 soft ranking in this world .

 

blesta is good and is not a complete piece of art in his category, this is the reality and you should accept it woth "FAIR PLAY" spirit   .

 

So how are they going to hack or exploit something which is just a button to upgrade, are they going to use ?fuckblestaup or ?activatetimebomb or upload a file to your server with a post form they made? or wave a magic wand?

[Blesta Addons]

So how are they going to hack or exploit something which is just a button to upgrade, are they going to use ?fuckblestaup or ?activatetimebomb or upload a file to your server with a post form they made? or wave a magic wand?

 

if you and me didn't know how they can , other maybe know how , because this is thier profession . we here just to minimize the risk of some way . i prefer listen other opinion , i know your opinion in tis subject .

 

i don't have the attention to continue in a false/positive conversation , the staff has the final decision  to accept or reject .

[mrrsm]

I will +1 this.

 

They tell you to take a backup before you upgrade just in case anything goes wrong.  If someone comes by and upgrades, it botches itself, I now have no recovery option past my last backup (assuming you are doing them).

 

 

What if you're not logged in, and now you can't login because of a MySQL error?

cli update.  If you have access to the server you may as well let them upgrade it

 

 

Blesta doesn't doesn't do holes.

There is no such thing as perfect software, as much as anyone would like there to be.  Security holes will pop up here and there no matter how hard to try to prevent them.  Blesta is great at addressing issues quickly.  An example would be CORE-1045.  That was a security hole, but they patched it very quickly.  Mainly what I am getting at is saying "Blesta doesn't doesn't [sic] do holes" is not putting forth a proactive feeling toward security.  Showing that they do have issues but treat them seriously and fix them in a reasonable amount of time shows they do care about security and do their best to keep things secure which is what the majority of people expect.

. 

 

Release Notes - Blesta Core - Version 3.0.9

## Version 3.0.9
2014-02-12

** Bug
    * [CORE-1045] - Security: Staff permission escalation through crafted URLs

---

 

[Michael]

I will +1 this.

 

They tell you to take a backup before you upgrade just in case anything goes wrong.  If someone comes by and upgrades, it botches itself, I now have no recovery option past my last backup (assuming you are doing them). 

 

You're supposed to back up before you upload the updated files... If your doing it back to front that's your fault.

[Michael]

There is no such thing as perfect software, as much as anyone would like there to be.  Security holes will pop up here and there no matter how hard to try to prevent them.  Blesta is great at addressing issues quickly.  An example would be CORE-1045.  That was a security hole, but they patched it very quickly.  Mainly what I am getting at is saying "Blesta doesn't doesn't [sic] do holes" is not putting forth a proactive feeling toward security.  Showing that they do have issues but treat them seriously and fix them in a reasonable amount of time shows they do care about security and do their best to keep things secure which is what the majority of people expect.

 

http://www.blesta.com/2014/02/12/security-advisory-staff-permission-escalation/

Active and valid staff members may be able to gain additional permissions through crafted URLs. Because this issue requires that the user have an active and valid staff member account, this is classified as a Moderate vulnerability.

Active staff, if your staff are being hackers that's your fault for hiring people who aren't trusted.

[mrrsm]

You're supposed to back up before you upload the updated files... If your doing it back to front that's your fault.

Human error is possible, you may have backed up the files but not the database.  You read the note that said make sure you have a backup so you go to backup the database and it gets ran in that time.  Again there isn't much that can really go wrong but why not make it safe?

 

http://www.blesta.com/2014/02/12/security-advisory-staff-permission-escalation/

Active and valid staff members may be able to gain additional permissions through crafted URLs. Because this issue requires that the user have an active and valid staff member account, this is classified as a Moderate vulnerability.

Active staff, if your staff are being hackers that's your fault for hiring people who aren't trusted.

Are you telling me that isn't a security hole though regardless if it is a staff account or not.  If one of my support peoples accounts was compromised they normally wouldn't have been able to do much damage unless they took advantage of the bug.

 

Overall Blesta is proactive is protecting people who use their software, they can't be expected to do everything for you but making minor changes that could help people that aren't a lot of work don't seem like a bad move to me.  Either way I trust the developers decision will be what is in Blesta's best interest. 

[Cody]

Since this is the intended result of this feature, I've moved to feature requests.

 

A few things to note:

1. Don't upload files until after you've already made a backup. The upgrade can not proceed unless the files uploaded are for a different version than the one currently installed.
2. If you've done step 1, it doesn't matter who processes the upgrade.
3. If we were to allow only 'authenticated upgrades' it would mean either:
   1. Upgrades can only be processed through CLI, OR
   2. Blesta would need to automatically handle the upgrade (download files/process upgrade)

 

It's way too risky to force someone to be authenticated in order to process an upgrade when the system is in an unstable state (i.e. the files are for a different version than the database).

[mrrsm]

1. If we were to allow only 'authenticated upgrades' it would mean either:
   1. Upgrades can only be processed through CLI, OR
   2. Blesta would need to automatically handle the upgrade (download files/process upgrade)

 

It's way too risky to force someone to be authenticated in order to process an upgrade when the system is in an unstable state (i.e. the files are for a different version than the database).

I am not sure why you wouldn't be able to authenticate the user in this case still?  You are most likely never changing the username/email and password fields in the database for users which means running a query against that shouldn't be much of an issue.  On top of that you control the upgrade script, that means you know that schema version (not sure if you track this or not as I haven't checked) which means you should be able to craft a query for any version of the users/groups/permissions tables if they did change.

 

I am most likely missing something though and probably should just look at the code at this point (which is my favorite thing about Blesta).

[Cody]

I am not sure why you wouldn't be able to authenticate the user in this case still?  You are most likely never changing the username/email and password fields in the database for users which means running a query against that shouldn't be much of an issue.  On top of that you control the upgrade script, that means you know that schema version (not sure if you track this or not as I haven't checked) which means you should be able to craft a query for any version of the users/groups/permissions tables if they did change.

 

I am most likely missing something though and probably should just look at the code at this point (which is my favorite thing about Blesta).

 

A user MUST be able to upgrade from version 3.0.0 to any future version. Any upgrade could completely change the database schema. So having the code expect one database schema but have a different one actually running is unstable. It's impossible to ensure backwards compatibility with a previous version's database schema, especially with EVERY previous version, as you imply with this authentication requirement. So we have no intention of even trying that. It's a waste of time.

[Blesta Addons]

A user MUST be able to upgrade from version 3.0.0 to any future version. Any upgrade could completely change the database schema. So having the code expect one database schema but have a different one actually running is unstable. It's impossible to ensure backwards compatibility with a previous version's database schema, especially with EVERY previous version, as you imply with this authentication requirement. So we have no intention of even trying that. It's a waste of time.

i don't know why you didn't want to protect the upgrade script frop unauthorized users !!

at least ask for licence number in upgrade , this is the simple way .

[interfasys]

License number or CLI only would work for us. It's only a problem in case of a botched upgrade imho, but still important as nobody wants any perp to be able to have access to that page while things are not working properly.

[Cody]

i don't know why you didn't want to protect the upgrade script frop unauthorized users !!

at least ask for licence number in upgrade , this is the simple way .

 

That would be simple for us, but most users don't know their license number, and a lot would have difficulty finding it.

[Paul]

What about an option in the config, that would restrict upgrades to authenticated users or CLI only? This would allow us to keep things working as they do now, for usability, but provide a way by which users could restrict the ability to run upgrades as suggested by making a minor change to the configuration file.

[Cody]

What about an option in the config, that would restrict upgrades to authenticated users or CLI only? This would allow us to keep things working as they do now, for usability, but provide a way by which users could restrict the ability to run upgrades as suggested by making a minor change to the configuration file.

 

That could be an option, but it wouldn't resolve the issue of code changes related to authentication.

If we're going to add an option to the config, we might as well add a token, and simply prompt users for this token when they wish process an upgrade through the web interface. That way the user can simply change it at any time via SFTP, and it doesn't rely on the authentication system matching the db schema.

[Paul]

That could be an option, but it wouldn't resolve the issue of code changes related to authentication.

If we're going to add an option to the config, we might as well add a token, and simply prompt users for this token when they wish process an upgrade through the web interface. That way the user can simply change it at any time via SFTP, and it doesn't rely on the authentication system matching the db schema.

 

I like this idea, what does everyone else think?

 

The question then, is whether to use http basic-auth or simply add a text input, if a token is set in the config.

[Michael]

Would it be good to do what someone suggested with the license key, but like on v2.x where you was getting the download files, so it calls home to Blesta to validate it as it would only be known to us (Blesta / License reseller) and the end user, but for some it means checking it every upgrade. But you can use it on CLI and GUI?

[PauloV]

my opinion

 

The best option is "license number", to get the upgrade download you have to login to the client area to download correct?, why not check the license? this way is more usefull for all and more secure on every aspect

 

the outher options are:

 

Wen uploading and executing the upgrade link, it will generate a token and send by email to all administrators staff this way we know the token to execute the upgrade