Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow members of plugdev group to execute rpiboot without root #27

Merged
merged 4 commits into from
Feb 4, 2020

Conversation

maxnet
Copy link
Contributor

@maxnet maxnet commented Dec 19, 2017

It would be nice if it was possible to execute rpiboot without root privileges.

To be able to talk to the device it's only necessary that the user has write permissions on the right /dev/bus/usb device node.
Give members of plugdev group access by udev rules.
As suggested by @ali1234 in raspberrypi/usbbootgui#3

Give members of plugdev group access to the usb device by udev
rules.
@ali1234
Copy link

ali1234 commented Dec 19, 2017

For reference, I suggested plugdev because this is the group you need to be in to use avrdude with USB programmers under Debian. It seems appropriate, but you could invent your own group for this if you wanted.

@maxnet
Copy link
Contributor Author

maxnet commented Dec 19, 2017

It's also used for other removable stuff like phones, cameras and storage.
And pi user is a member of it by default, so fits the bill.

@@ -332,6 +332,12 @@ FILE * check_file(char * dir, char *fname)
FILE * fp = NULL;
char path[256];

// Prevent USB device from requesting files in parent directories
if(strstr(fname, ".."))
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason for this? Can you just add an error message to explain why this is disabled?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patchset aims to make it safer to allow unprivileged users in multi-user setups run rpiboot, without effectively handing them the keys to the entire system.

rpiboot essentially is file server software handing out whatever file any attached USB device claiming to be a Raspberry Pi asks for.

If I enter rpiboot /usr/share/rpiboot/msd I have the reasonable expectation that the file server code only shares my /usr/share/rpiboot/msd folder with the connected device.
However currently nothing prevents a device to ask for a file name like ../../../../etc/shadow, which will get translated to /usr/share/rpiboot/msd/../../../../etc/shadow and serve /etc/shadow

Simply rejecting any request with a .. in it is the simplest form of protection against directory traversal attacks like this.
Could also turn the path provided into an absolute path first and verify if that is within the path allowed however that requires platform specific code.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also note that this isn't completely mitigated by dropping root. It could also try stuff like ../.ssh/id.rsa to steal your ssh key.

+1 for adding an error message. Also since you removed the sudo check error message, I think a new error message should be added at whatever point the transfer fails if the user is not in plugdev.

Copy link
Contributor Author

@maxnet maxnet Dec 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction: it does allow enumeration without privileges.
Added a patch to print a message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to see the path traversal patch being merged soon, testing against a stock rpiboot as expected it happily sends "../../../../etc/shadow".

Found serial number 1
Second stage boot server
Received message GetFileSize: ../../../../etc/shadow
File size = 885 bytes
Received message ReadFile: ../../../../etc/shadow
File read: ../../../../etc/shadow

And with the "Disallow requests for files outside directory" patch it's denied.

Second stage boot server
Received message GetFileSize: ../../../../etc/shadow
Cannot open file ../../../../etc/shadow
Received message ReadFile: ../../../../etc/shadow
No file ../../../../etc/shadow found

* Error out if permission was denied while opening device.
* Show error if request for file containing .. was denied.
@simonvanderveldt
Copy link

@ghollingworth Is there anything that needs to be done before this can be merged? Would be nice to get it in, both because of the vulnerability and to make it easier/more secure without sudo.

@ghollingworth
Copy link
Contributor

@maxnet You happy with this in it's current state?

@maxnet
Copy link
Contributor Author

maxnet commented Feb 20, 2018

Am happy with it.

Be aware it has only been tested under Linux though, and not under MacOS and such.
Not sure how permissions work with that, and wheter or not a different message than "Make sure you are member of plugdev group" should be printed there. Or if user always has permission, and that is not an issue.
Leave that up to you.

@malnvenshorn
Copy link

I think the preferred way would be to use the uaccess tag.

@zpfvo
Copy link

zpfvo commented Feb 4, 2020

Why wasn't this merged for so long? #44 is absolutely right.

@ghollingworth ghollingworth merged commit 86f6453 into raspberrypi:master Feb 4, 2020
bencord0 pushed a commit to bencord0/rpiboot that referenced this pull request Nov 28, 2020
…errypi#27)

* Do not require root privileges

Give members of plugdev group access to the usb device by udev
rules.

* Disallow requests for files outside directory

* Be more verbose about errors

* Error out if permission was denied while opening device.
* Show error if request for file containing .. was denied.
@dcousens dcousens mentioned this pull request Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants