search

volumio / Volumio2

Volumio 2 - Audiophile Music Player
http://volumio.org
Other
1.37k stars 316 forks source link

[RPi] Plugin Installation Breaks when the OS Password is Changed #1192

Open mkonersmann opened 7 years ago

mkonersmann commented 7 years ago

Version: 2.175 Platform: Raspberry Pi

I installed the Raspberry Pi image and changed the user password for the OS via SSH. Now the installation of the Youtube Plugin fails.

The "details" section in the UI did not help:

Downloading plugin at http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
END DOWNLOAD: http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
Creating folder on disk
Unpacking plugin
Checking for duplicate plugin
Copying Plugin into location
Installing dependencies
The following error occurred when installing the plugin: Error

The log says:

volumio@volumio:~$ tail -f /var/log/volumio.log
2017-05-28T08:41:00.371Z - info: Downloading plugin at http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
2017-05-28T08:41:01.793Z - info: END DOWNLOAD: http://volumio.github.io/volumio-plugins/plugins/volumio/armhf/music_service/youtube/youtube.zip
2017-05-28T08:41:14.350Z - info: Checking if plugin already exists
2017-05-28T08:41:14.355Z - info: Rename folder
2017-05-28T08:41:17.669Z - info: Move to category
2017-05-28T08:41:46.801Z - info: Checking if install.sh is present
2017-05-28T08:41:46.806Z - info: Executing install.sh
2017-05-28T08:41:48.692Z - info: Install script return the error Error: Command failed: echo volumio | sudo -S sh /data/plugins//music_service/youtube/install.sh > /tmp/installog
[sudo] password for volumio: Sorry, try again.
[sudo] password for volumio: 
sudo: 1 incorrect password attempt

2017-05-28T08:41:48.696Z - info: An error occurred installing the plugin. Rolling back config
2017-05-28T08:41:48.696Z - info: Plugin folders cleanup
2017-05-28T08:41:48.697Z - info: Scanning into folder /volumio/app/plugins/
2017-05-28T08:41:48.697Z - info: Scanning category audio_interface
2017-05-28T08:41:48.698Z - info: Scanning category miscellanea
2017-05-28T08:41:48.699Z - info: Scanning category music_service
2017-05-28T08:41:48.700Z - info: Scanning category plugins.json
2017-05-28T08:41:48.701Z - info: Scanning category system_controller
2017-05-28T08:41:48.702Z - info: Scanning category user_interface
2017-05-28T08:41:48.703Z - info: Scanning into folder /data/plugins/
2017-05-28T08:41:48.703Z - info: Scanning category music_service
2017-05-28T08:41:48.704Z - info: Plugin youtube found in folder but missing in configuration. Removing folder.
2017-05-28T08:41:52.421Z - info: Plugin folders cleanup completed
2017-05-28T08:41:52.423Z - info: Error: Error
2017-05-28T08:41:52.426Z - info: Folder /tmp/downloaded_plugin removed
2017-05-28T08:41:52.427Z - info: Folder /tmp/downloaded_plugin.zip removed

I thought about resetting the password to the default, but the OS won't allow me:

volumio@volumio:~$ passwd 
Changing password for volumio.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
Bad: new password is too simple

I propose an information. Try a simple command first (sudo echo 1). If it fails, show a message The password for the system user 'volumio' has been changed. Please use the install script ... via SSH. (Those wo know how to change the system password might also know how to start a script via SSH). However, the install script is not available, because it has been deleted so fast.

Alternatively you could prompt for the password, but this has security implications, because the UI transmission is not encrypted #1166 and this would expose the sudoable user password to the network.

volumio commented 7 years ago

This is an issue: since now we would like to change default pw for user volumio, we need a way to execute the install script as volumio but with sudo. Ideas?

mkonersmann commented 7 years ago

I created a pull request #1193, which simply removes the sudo call. I was able to install all current plugins with that version.

This obviously contradicts with your statement:

we need a way to execute the install script as volumio but with sudo

Why do you need root for plugin installation? For future plugins?

xipmix commented 7 years ago

see also #948

dhoffend commented 7 years ago

There are lots of echo "volumio" | sudo calls. Maybe it's worth changing the sudo rules to "nopasswd" and specify them more clearly

dhoffend commented 7 years ago

IMO you should do the following things

1) disallow the user volumio to login via ssh (sshd_config or pam) at all (no need for). Then you can keep your default password or remove the password completly 2) create a normal user (like the pi user) that can login and which password can be changed. for normal administrative tasks

Alternative: fix the sudoers rules so everything can be executed using nopasswd. Then the scripts don't need to pass a hardcoded password in the control and pluginmanager scripts

Disabling SSH Login is completly useless as long as you can reenable it via WebUI without any form of authentication. This does not really prevent the abuse of the volumio player as an attackable IOT Device.

suuuehgi commented 6 years ago

Access to the system without authentication (as with the web-gui) is obviously bad. Did you think about creating two users? One for system management and the core infrastructure and one for the user. The ssh login for the former can be denied via /etc/ssh/sshd_config but ssh logins in general be kept up.

JonathanHuot commented 6 years ago

To preserve safety of my local network, I have generated a pair of ssh-keys and added it into volumio user. Then, I enabled PasswordAuthentication only for localhost. That way, Volumio processes continue to work as expected, and then I am still able to connect to the volumio server with my ssh key.

What if, by accident, I loose my private key ? Well, I am able to plug a monitor and keyboard to revert the changes.

Steps:

  1. Enable SSH in http://volumio/dev (have a look at https://volumio.github.io/docs/User_Manual/SSH.html)
  2. Generate a pair of ssh key, if needed ssh-keygen
  3. Add it to volumio ssh-copy-id volumio@volumio
  4. Log into volumio and change ssh settings: 
    $ ssh volumio@volumio
$ sudo su
# cat <<EOF >> /etc/ssh/sshd_config
PasswordAuthentication no
Match Address 127.0.0.1
  PasswordAuthentication yes
EOF
  5. Restart sshd # service sshd restart
manin22 commented 5 years ago

Here you are workaround I'm using quite a long time which can improve the security allowing to use non-default password for ssh access.

  1. log-in as volumio user and change the default root password

    volumio@volumio:~$ sudo -i
root@volumio:~# passwd root
Enter new UNIX password:

  2. enable root and restrict volumio ssh login

    root@Volumio:~# nano /etc/ssh/sshd_config
...
PermitRootLogin yes
...
Match User volumio
    PasswordAuthentication no

  3. apply changes via sshd restart

    root@volumio:/home/volumio# /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.

Using this setup, I have never had any trouble with the system upgrade or plugin installation. If you need to work under volumio account (e.g. for devel. plugin installation), just log in as the old school root user and switch to volumio user:

root@volumio:~# su - volumio
volumio@volumio:~$
volumio commented 5 years ago

Sorry but this seems to be a worst solution than what it cures: you enable directly root login

manin22 commented 5 years ago

disagree ;-) I don't see anything wrong with using root login protected by strong password in private home network. It is the same like other well known user name with sudo privileges and much better than volumio account protected by default password.

xipmix commented 5 years ago

This triggered a couple of thoughts. I'll throw them out there in hopes of stimulating more thoughts.

mbrennwa commented 5 years ago

Why does plugin installation need sudo / root access? Everything else in the web GUI does not require anything like that. Awkward. (Yes, one could argue that manipulating the system in the web GUI should require a password.)

On another note, what about running the plugin installer on a terminal (not via the web GUI)? Is is possible to run the installer with sudo / root permissions? This would at least allow plugin installation on the terminal (via ssh access).

buzuck commented 4 years ago

I agree with @mbrennwa, a root acces shouldn't be needed here. As (almost) all files in /volumio belong to, well, volumio, no sudoing should be required.

This is even dangerous, as plugins could execute some weird code.... 🤔

WarmChocolateCake commented 4 years ago

I see from some plugins that they are installing (and removing!) other OS packages, which would need some form of privilege - but (IMHO) that's not a "plugin" - that's another "application" (which happens to be closely coupled with volumio) Having sudo without a password is not a solution (again, IMHO) So, how about the plugin "Install" button asking for the password? This would ensure that the plugin can only be installed by the user AND it would mean that the password can be changed.

xipmix commented 4 years ago

+1. That means you have to have a keyboard of some kind available when installing plugins, but OTOH it is an action that is probably best done sitting in front of a computer, paying full attention.

There are some mods to system files that volumio needs to do, which requires root permissions. However having an explicit list of commands that can be sudoed with no password should be ok for most of that. The sticking point for this issue has been arbitrary commands that plugins want to run, so requiring a password for that case only may be reasonable. Not quite sure how difficult feeding the input password to sudo will be. (edit) Then we circle back around to changing the password, over an unencrypted web link, from the factory default. I keep thinking that offering to change it in the startup wizard might be enough, and once that has been done then ssh for the volumio user could be enabled again. Of course the plugin dialog won't be encrypted either, so any later use also exposes the password...

ashthespy commented 4 years ago

We could always send the password from the webUI to the backend, sure it is not over https, but it would be better than the current situation?

xipmix commented 4 years ago

I agree, better than where we are now, particularly if it is a one-time change at installation, or a once-in-a-while change, at most.

WarmChocolateCake commented 4 years ago

That means you have to have a keyboard of some kind available when installing plugins

Not necessarily... on my Android device, the pop-up keyboard appears when needed, so I don't see that as an issue.

We could always send the password from the webUI to the backend, sure it is not over https, but it would be better than the current situation? Yeah, this is what I had in mind with the Install button, (but hadn't put into words)

However having an explicit list of commands that can be sudoed with no password should be ok for most of that. I'd be cautious of this approach (but I don't have a better suggestion). It will start with "just" a few commands, and then more & more will be added (and none removed). There should really be a single approach for both the volumio core AND for plugins.

xipmix commented 4 years ago

Further thought has brought me to a series of steps like this:

At this point a savvy user could login over ssh and change it if they want.

After that has run, the only way to change the password is to ssh in and run 'passwd' (unless of course there's a way to make it run again, then you might have to put in a check that the current password is the expected image default and skip that step if not).

I think this gradually improves the current situation without requiring a lot of change at one time. It also avoids the network eavesdropping issue except for one occasion. After that perhaps we can start getting rid of the 'cat /data/password' calls.

Disabling ssh access by default is still a good idea and I think we can leave it that way.

volumio commented 4 years ago

@xipmix I really like your approach, seems this offers the best balance between security and flexibility. Would you be willing to work on it and submit PRs? If yes, that woud be awesome and I'll actively cooperate

xipmix commented 4 years ago

Sure. Actually there seems to be only one place where the 'echo volumio' idiom is still in use, pluginmanager.js. A lot of good work has being going on while we've been dithering here. Maybe this is less work than we feared.

volumio commented 4 years ago

Hope so ;) Thanks for helping out on this

WarmChocolateCake commented 4 years ago

Just re-read an earlier post:

* add /data/password, containing the current password. The image gets built with this file.
  After the first image with that file is released, start work on the backend

* convert all hardcoded usage in the backend to 'cat /data/password', one module at a time.

This is just moving the problem around.

Password security is not done by checking whether the password matches - instead - a hash of it is checked. So, the workflow should be (similar to):

  1. User enters a password
  2. Password is hashed (let's just say SHA256 - I must admit that I don't know what hash is best here)
  3. The HASH is stored
  4. Any time a password is required to add / update something, then the user is prompted for the password and it's compared to that hash.

The point is here, the user is totally aware of when Volumio is trying to do something AND we have improved security :)

xipmix commented 4 years ago

The logical place to store that hash would be the /etc/shadow file, so what you are proposing here boils down to "prompt the user for every sudo invocation that requires a password", which is a significant change of user experience. It also exposes the password on the network since the connection is over http, not https (see comments above). On the other hand, AFAIK at present the only sudo calls that need a password that are left is plugin installation and removal. So maybe this is something that could be done in a further iteration.

geek-merlin commented 4 years ago

Imho the best step forward is:

Of course we can do a lot more, but this may be a start.

mbrennwa commented 4 years ago

Working with the SD card would require physical access, which is not always possible.Am 31.01.2020 01:13 schrieb geek-merlin notifications@github.com:Imho the best step forward is: Prevent all ssh password logins by adding PasswordAuthentication no to file /etc/ssh/sshd_configOn help pages and/or volumio.local/dev page, add instructions If you want to login via ssh, mount your SD card to your computer, and with root permissions, put your SSH key in /home/volumio/.ssh/authorized_keysPlease never change the password of the volumio user, as the plugin system currently needs this. If you accidentally changed the password, mount your SD card to your computer, and with root permissions, replace the line starting with "volumio" with this line: ...

Of course we can do a lot more, but this may be a start.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

xipmix commented 4 years ago

This idea of manually installing an authorized_keys file has merit, it saves having to modify the wizard and installing fail2ban. But it seems rather easy for it to go wrong and frustrate the user. For example making sure 'volumio' and not 'root' owns said file... Perhaps an automated chown && chmod at boot time can ensure this isn't a problem. Another option would be to do the ssh key upload as part of the firstrun wizard, if that doesn't complicate that process too much. The manual approach should be added to the 'good to know' section of the docs, in any case.

The question of physical access doesn't seem a big problem to me, you have to burn an image to the card at some point and shortly after that, run that firstrun wizard.

I do think it is useful to be able to change the volumio user password if the user desires this, but that could be implemented in a later iteration.

mbrennwa commented 4 years ago

On Fr, 31 Jan, 2020 at 05:31, xipmix notifications@github.com wrote:

The question of physical access doesn't seem a big problem to me, you have to burn an image to the card at some point and shortly after that, run that firstrun wizard.

This assumes that the SSH keys will never change after the first set up. This may (will!) not be the case in many situations. For instance, in my environment the computers and user accounts that need to access the volumio boxes change quite often. Turning all volumio boxes off, accessing the SD cards, fiddle with the SSH keys, copy them to the SD cards, and reboot all volumio boxes every time is simply not possible.

Disabling password access is not a "fix" for the root problem that the password is hardcoded in some spots. I don't understand why Volumio can't just ask the user for a password whenever it's needed (be it SSH or the web UI).

xipmix commented 4 years ago

Is it true in your environment that once you have one ssh key set up, you could do all later changes over the network? That's what I was envisaging, that the physical access upload would only need to be a one-time thing. (You may also be interested in this talk from LCA, by the way - https://linux.conf.au/schedule/presentation/54/)

I agree disabling password access doesn't address the root problem. It would be interesting to hear what @volumio thinks about the UX impact of being prompted for passwords at regular intervals.

There's another issue though - the generation and use of ssh keys. My guess is the number of volumio users who have the faintest idea how to work with SSH keys is rather small. That's not to say it shouldn't be supported, but there may still be a significant need for password-based access.

volumio commented 4 years ago

Thanks guys for this interesting conversation. IMHO the best sum of all proposals is:

What do you guys think?

xipmix commented 4 years ago

I'm not following.

I'm not aware of an include mechanism for /etc/shadow. How are you thinking this would be implemented - with some boot-time rebuild of /etc/shadow from shadow.base and shadow.extra files?

Also unclear about how to implement the change-on-first-ssh; chage is the normal mechanism but it will only update /etc/shadow. Something else is needed to save the encrypted password to a separate file and the plaintext to /data/userpw. Or are you meaning this would be done in the wizard?

I agree ssh keys is somewhat niche.

geek-merlin commented 4 years ago

OK nice to have a discussion about that. So let me elaborate more.

Unsecured IoT devices are quite common these days, but the more we get of them, and the safer the desktops get, the more interesting attack targets they are. Also as an attacker, you can hibernate your trojan in an IoT device, even if the victim scrubs their desktop computer. So it is foreseeable that we will have massive IoT attacks some day.

For any black hat, Volumio users will be attractive fraud targets ("If there are some users that pay for oxygen free cables more than my month's salary, i want their credit card data" (if this is true or not does not matter ;-)). I'll spare the details but from there it's script kiddies' work.

That said, we can have different estimate how difficult or likely attacks are, but one thing for sure: The main question is, what is between an attacker and Volumio root access. A user password is not the answer, as evidence shows too many user passwords are easy to dictionary-attack.

So let me strongly advise: If a user wants to SSH, teach them to ssh-keygen. With great power comes great responsibility.

WarmChocolateCake commented 4 years ago

Thanks guys for this interesting conversation. IMHO the best sum of all proposals is:

  • The etc/shadow file will not contain the volumio line, which will be added in a separate file via an include.
  • We can request ssh pw change at first ssh connection. And store such password in the included ssh line (this way it will survive updates, while avoiding to impact global shadow file
  • We also store the pw under /data/userpw . This variable will be read by the plugin installer when it needs to install a plugin
  • SSH keys is too much of a nieche request to be taken into consideration

What do you guys think?

Please, do NOT store the password - anywhere.

If you want to store something, compare it with a hash (which is the purpose of /etc/shadow), but never store the password.

@geek-merlin has some interesting points - for a physical device with a removable storage card, that process is possible, but if it's running on an embedded device (ie inside a box), or perhaps a VM, then that might not be the best approach for a generic IoT application like this one.

So, my opinion would be - for "normal" GUI operation:

  1. Ask the user for a password during installation (and there is NO default... none... not even "blank"... just like joining the Wifi - there's no default Wifi SSID)
  2. Store it using standard, secure implementations (ie /etc/shadow, etc)
  3. Whenever elevated privileges are required, ask for the password and compare to the hash.

I'm not sure how much administration via the "volumio" command line interface is done, but I presume that this needs to be done with the same elevated privileges, so it may be better to SSH into the device as a "normal" user (and obviosuly that can be via password or keys) and then use the sudo mechanism to elevate privileges.

Keeping it as standard as possible should be better for maintenance as well as end-user familiarity.

geek-merlin commented 4 years ago

Thanks for the comment.

Ask the user for a password during installation (and there is NO default...)

That ignores the fact that user-provided passwords are not secure enough for root access.

but if it's running on an embedded device (ie inside a box), or perhaps a VM, then that might not be the best approach for a generic IoT application like this one.

Yes i get the point. I wonder if this is in prod anywhere, but let's assume it is. You can still get strongly secured root access if you want. Ask the user to upload an SSH key OR download a private key, done. Just one example.

stevehurcombe commented 3 years ago

Hi, I'm new to Volumio and whilst it's great piece of software this is a big issue. It's now 2021...is anything going to happen about this?

paviro commented 2 years ago

2022 and I just stumbled upon this when changing the volumio password. This actually makes me reconsider continuing using Volumio altogether feels like a very insecure architecture this way.

Disabled password login for now still a strange decision to do it this way.

WarmChocolateCake commented 2 years ago

The UK plan to make default passwords "illegal" (with fines...), so this issue will need to be addressed at some point: The Product Security and Telecommunications Infrastructure (PSTI) Bill

There's standard solutions for this problem, so I'm surprised by the conversations earlier in this thread asking about how to implement it...

I was waiting for v3 to stabilise (ie my hardware to be supported) before I had a look at this again... is it still the same on v3?!

I noticed that the plugins now needed a (free) volumio account before they could be installed, so I was hoping that the whole plug-in design had been revamped...

afonsoguerra commented 3 months ago

Come on, it's 2024 now... please don't tell me the Volumio products also have a default password? Such a great software otherwise, but completely unusable in a reasonably secure environment due to this issue... how disappointing.