1

I asked this question over on the Raspberry Pi forums in an attempt to keep it low key, but I can't seem to find it now, so I'll ask it here. It is on-topic and definitely specific to the Raspberry Pi.

There is a lot of news in the security channels recently about a local exploit on Apple OS X that allows a non-authorized user to append a line to the sudoers file to allow the use of sudo without entering credentials. The Register has an article describing the exploit. Essentially, a user with local access can add themselves to the sudoers file to bypass password authentication for use of sudo.

[edit]My question isn't about the exploit, but rather the implications: A user able to use sudo to execute root commands without entering credentials, particularly when coupled with an account that ships exposed (on raspbian) to the network with a well-known default password

I don't see how the resulting situation on an Apple is fundamentally different than the default situation on a RPi. A non-root user is able to execute root-level commands without entering credentials.

Obvious differences: 1. A user on the Mac not in sudoers can add themselves. 2. The default 'pi' user account on every raspbian install has a fixed, well-known password as well as ability to execute root commands with sudo. 3. [Edit] The RPi, by default, listens on the network.

So which is the bigger deal? A Mac user who could elevate procedures if and only if they have access, or an RPi with a default password and the same access?

  • Shouldn't the same fuss be made about raspbian?
  • Where would a new raspbian user reasonably be expected to be made aware of this issue and how to fix it before connecting to the outside world?

[edit]It has been pointed out that was is a Raspberry Pi foundation decision and not raspbian, debian or linux per se. Nearly every other Linux distribution I've used over the last 10 years has required creation of a new user account with a non-default password, as well as the use of the password when executing sudo commands as the initial user.

[edit]The near immediate discussion about possibly voting to close indicates to me that the idea of a security issue on raspbian isn't considered as seriously as similar threats on other platforms. Is honest discussion about the topic is not welcome here?

  • 2
    I'm not convinced that a security breach which only affects a specific version of a non-Linux OS is relevant to the Raspberry Pi. – joan Jul 23 '15 at 19:48
  • It definitely is relevant to the RPi: The breach enables the same settings that are default on the RPi. Sudo works the same way on OS X. How can it be a bad thing on one platform, and perfectly normal on the one we happen to love? Thanks for simply downvoting and not deleting or otherwise mangling though. Would have preferred to discuss quietly on RPi forums, but... – bobstro Jul 23 '15 at 20:01
  • As it happens on this occasion I didn't downvote. On the Mac it is a breach as the root permissions are gained by a non-root user. On the Pi it's not a breach as the root permissions are gained by somebody who is specifically permitted to have root permissions. Personally I don't like password free sudo access by default. I don't think that's Raspbian, but the Foundation's build of Raspbian. I do feel that the Foundation should make clear the importance of setting a new password as soon as possible. So I think to blame Raspbian would be wrong on both those issues. – joan Jul 23 '15 at 20:10
  • Mea Culpa then, and thank you for not downvoting. I just find it incongruous that the resulting access is being played as a big deal on one platform, but "by design" on the other (the Microsoft defense for years). The fact that the RPi ships with a default password makes it a more critical issue, IMO. Particularly concerning how many posts here relate to connecting the RPi to the Internet, whether that was the original RPF intent or not. So "blame" belongs with RPF then? – bobstro Jul 23 '15 at 20:13
  • I agree w/ joan that it really isn't relevant, but since it involves a fear that some people may worry is, I haven't voted to close. I know that there is a lot of at least apparent inconsistency WRT on/off topic here and I feel bad about that, but I think it has to do with the fact that we can't afford to be 100% strict or completely lenient. Unfortunately that's bound to produce some bad feelings regularly :( -- just be glad this isn't the NTSB. – goldilocks Jul 23 '15 at 20:45
4

The vulnerability described in that article sounds like a complete and total disaster that Apple should be hussling to fix ASAP.

However, it obviously won't work on GNU/Linux including Raspbian. With regard to resembling the issue of the default privileges given to Raspbian's pi user, I'll point out two very significant differences:

  1. The pi user in /etc/sudoers is a matter of intentional configuration, which can easily be changed in minutes. In contrast, an unintentional bug of the sort involved with DYLD_PRINT_TO_FILE cannot be changed by the user, period. If you own an OSX system with this problem, there is absolutely nothing you can do to protect yourself from it whether you know about it or not. The system requires a linker.

  2. Going back to what "intentional" means: It is explicit. If you understand how the system works, then you will recognize it is possible for a user with the pi password to execute total FUBAR commands. This is not a mistake or a secret. It's right out in the open from the beginning.

For me, #1 is the primary point. If you don't like this kind of set-up (I don't) then change it. This could be as simple as deleting user pi, or even more simply, just changing pi's password after you install. Most people presumably will do that (unless they don't think any one else can gain access to the system) out of plain common sense. This is the online, digital information age after all. If I sold you a computer and said, "The admin user is 'admin' and the password is 'FUBAR', just as it is originally for all computers of this type," you'd probably ponder that a little ("Hmm, so if someone else who owned one of these knew this they might try to see if I'm still using the default password..."). This is the norm for household routers, I think.

People who are completely computer illiterate, do not understand the significance of passwords, etc. are really unlikely to want an Rpi, and if they do, there is probably a lot more grief waiting.1

Again, I don't mean by this that I feel it is a good practice and will not guess as to why Raspbian, decided to do this (normal Debian does not); perhaps because they felt it made a potentially intimidating process less prone to stress and error. Which I'm sure it does. However, it is also a good example of how things can be dumbed down to the point of potential calamity.


1. Which raises a question about user-friendliness, etc. On this front I'd make a point about GNU/Linux that I think many people used to purely commercial software may miss because the meaning of it may be sort of incomprehensible to them: No one sold it to you, and probably no one responsible for it even asked you to use it; Raspbian is a bit gray in this but it is still the case. Even if you bought a card with Raspbian installed, what you were paying for was not Raspbian, it was the card, and having someone burn it.

I'm pointing this out because it is then worth asking who is it that produces such software and why. Was it you? If not, was it to please you? Perhaps not. Hence, beware that this is not a normal consumer pays corporation relationship. You are responsible for yourself here, and nobody owes you anything.

  • A few points: Apple does generally provide cautions about allowing remote access. To your point on explicit, the creators of raspbian made that explicit decision, but I think many new users are completely unaware of it. Being familiar with Linux in general, I was quite surprised. Again, question is, intentional or not, what is distinction if end result is the same? As to the intended audience: Witness the questions here regarding doing things not expected of an educational device. I worry about the security impact. These things show up in workplaces or on the Internet, regardless of "plan". – bobstro Jul 23 '15 at 22:25
  • I want to emphasize again, 1) That this really isn't a "security threat" of the same order, 2) What Apple is, as a hierarchical legal entity, vs. the realm which made the pi possible. IMO this choice was not well advised on behalf of Raspbian, but realize there's some arm's length between them and the Rpi Foundation...and between them and Debian, and Debian and GNU, and GNU and Linux. Who's responsibility is it to inform all Rpi users of this issue? They are not linux customers, or Debian customers, or GNU customers, and ultimately, not even Raspbian "customers". – goldilocks Jul 24 '15 at 0:57
  • The thing about users being left "completely unaware" is certainly already an industry standard, even if it is hidden behind "tick the box to agree you agree" legalities. Has Apple made any effort to inform users about this latest vulnerability? I'm not intending to bad-mouth them, or to use their practices as a defense of anything, but just to point out that using computers does require a certain amount of literacy, and the organizations and such involved with them do not, on any scale, accept liability for your ignorance.. – goldilocks Jul 24 '15 at 0:58
  • It is good you have brought this up to help other people understand, but it isn't a flaw in the same sense that brakes stopping a car is not a flaw just because they don't work if you don't use them. In case you don't get that, we licence drivers. But we don't license computer users the same way we don't license cake bakers; if you screw up, boo-hoo that sucks, but not in a serious way for others, so you are free to try, buy, and experiment with what you want. I presume that the Raspbian folks made a decision they would stand by. In any case, it isn't a genuine security flaw. – goldilocks Jul 24 '15 at 1:00
  • Interesting point about certification/licensing users, although focus of RPi on "education" leaves room for debate about whether teaching security fundamentals should be part of that. So is your answer that it's less of an issue on the RPi because it's by design and not the equivalent consequences? Please refrain from lines like "in case you don't get that." – bobstro Jul 24 '15 at 2:13
2

The exploit revolves about the environment variable DYLD_PRINT_TO_FILE, which the RPi does not have. From the link that you provided.

It's all possible thanks to an environment variable called DYLD_PRINT_TO_FILE that was added in Yosemite. It specifies where in the file system a component of the operating system called the dynamic linker can log error messages.

This environment variable has only been introduced in Yosemite. So the earlier versions of OS X do not suffer from this exploit. Neither does the RPi.

  • Understood that the exploit doesn't exist on the RPi, but the resulting access is the same, with the difference that, by default, a would-be attacker knows the account password of the 'pi' user on the RPi. My question wasn't whether the exploit exists, but whether it's an issue of equal concern. – bobstro Jul 23 '15 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.