Linux devices and root password

This is the first time I release an embedded device based on Linux OS 
(it runs on iMX6ULL CPU).

This device will be produced in a medium scale (100-1000 pieces). I'm 
thinking about root password: should it be the same on all the devices, 
or should it be different?

Each device has a different 4 bytes serial number. I could use it to 
scramble an unencrypted password and obtain an enctrypted password that 
will be the normal root password.

I could disable SSH service at all to be safer, but anyway the board has 
a console over UART that I don't want to disable.

Any suggestions?

pozz <pozzugno@gmail.com> wrote:
> This is the first time I release an embedded device based on Linux OS 
> (it runs on iMX6ULL CPU).
> 
> This device will be produced in a medium scale (100-1000 pieces). I'm 
> thinking about root password: should it be the same on all the devices, 
> or should it be different?

If it's the same and network accessible, it'll get added to databases of
root passwords that get used for exploits.  Doing that is also forbidden by
law in some jurisdictions (eg UK).

> Each device has a different 4 bytes serial number. I could use it to 
> scramble an unencrypted password and obtain an enctrypted password that 
> will be the normal root password.
> 
> I could disable SSH service at all to be safer, but anyway the board has 
> a console over UART that I don't want to disable.
> 
> Any suggestions?

Having a fixed root password that's only accessible via a UART inside the
case is safe, but not if via network.

Disabling SSH if the customer doesn't need it is generally a good idea, since
it's just another channel for attacks (or, even if not vulnerable, it
creates noise in your logs/IDS).

Standard best-practice is to provision a unique password but to print it on
a label on the device (eg on the back or underneath) so physical access is
needed to discover it.

Do you have a provisioning flow where new devices get loaded with their
firmware, MAC address and similar identifiers?  Could you set the password
there?

Theo

Il 30/08/2023 18:14, Theo ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> This is the first time I release an embedded device based on Linux OS
>> (it runs on iMX6ULL CPU).
>>
>> This device will be produced in a medium scale (100-1000 pieces). I'm
>> thinking about root password: should it be the same on all the devices,
>> or should it be different?
> 
> If it's the same and network accessible, it'll get added to databases of
> root passwords that get used for exploits.  Doing that is also forbidden by
> law in some jurisdictions (eg UK).

The device will be connected to Internet, but I'm going to disable SSH, 
because the application and the user won't need it.

The password here is the **root** password, where root is the Linux root 
user, not an admin user.

The device runs a web server and the user can interact with it with a 
standard web browser. The web application is protected by a login 
(username and password), but the "web users" are different from Linux 
root user.

The default web user will be admin/admin and hopefully the user will 
change the password at the first login.

This post refers to Linux root user that isn't normally exposed to the 
end-users, mostly if I disable SSH service.

My concerns are for someone with sufficient technical skills that wants 
to enter the Linux system. The first thing he would do is finding the 
console UART, connect/soldering a USB/UART converter, open putty and try 
to login guessing the root password.

The original question was for this scenario.


>> Each device has a different 4 bytes serial number. I could use it to
>> scramble an unencrypted password and obtain an enctrypted password that
>> will be the normal root password.
>>
>> I could disable SSH service at all to be safer, but anyway the board has
>> a console over UART that I don't want to disable.
>>
>> Any suggestions?
> 
> Having a fixed root password that's only accessible via a UART inside the
> case is safe, but not if via network.

So in my case is safe, because via network SSH will be disabled and web 
application uses different credentials.


> Disabling SSH if the customer doesn't need it is generally a good idea, since
> it's just another channel for attacks (or, even if not vulnerable, it
> creates noise in your logs/IDS).
> 
> Standard best-practice is to provision a unique password but to print it on
> a label on the device (eg on the back or underneath) so physical access is
> needed to discover it.

It's useless in my application. The end-user will never need the Linux 
root password, only an hacker would need it and I wouldn't show him the 
password well printed on a label.


> Do you have a provisioning flow where new devices get loaded with their
> firmware, MAC address and similar identifiers?  Could you set the password
> there?

Yes, in case I choose to set a different Linux root password for each 
device, the choice of password will be done during programming of 
firmware and so on.

In this case I can generate a random password, saving it in a database 
of devices. However, the time I need to enter the system (if something 
goes wrong and I need to read logs or issue commands), I need the serial 
number and the database.

If I generate the password from the serial number using a well-known 
algorithm, I could always recover the Linux root password from the 
serial number only.

I'm wondering if there was a standard or typical approach here.

pozz <pozzugno@gmail.com> wrote:
> This post refers to Linux root user that isn't normally exposed to the 
> end-users, mostly if I disable SSH service.
> 
> My concerns are for someone with sufficient technical skills that wants 
> to enter the Linux system. The first thing he would do is finding the 
> console UART, connect/soldering a USB/UART converter, open putty and try 
> to login guessing the root password.
> 
> The original question was for this scenario.

It depends whether the customer is your adversary or not.

If you want to prevent the customer having access, eg because hacking the
device would cause them to get free service or similar, then preventing root
access is a roadblock for this.  Or if the device has users whose motives
aren't aligned with the customer (eg it's installed in a public place where
people might tamper with it).

If the customer has bought the equipment and there is nothing the customer
or their users can illicitly gain access to, I'd suggest leaving a default
root password on there - it enables the customer full access to a device
they own and have physical access to, and gives them options for extending
the use of the device once its original purpose is ended (eg if you stop
supporting it).  If they choose to break their device, that's their problem.

(some devices set a 'warranty void' bit if unauthorised firmware is loaded,
to avoid having to handle warranty claims on modified devices.  Only some
SoCs have such non-resettable 'e-fuses')

I'm also assuming there are no other interfaces which might render any
password protection moot - like being able to unplug the flash storage and
change the password in another machine, or being able to use JTAG to
reprogram the flash chip.  If so, it may be simply a matter of difficulty -
pulling an SD card is easy, soldering to testpoints to access JTAG lines
less so.

One other thing, though.  If you have a fixed root password, make sure you
ensure that regular user processes can't 'su' to root.  Otherwise any
networked user who is able to inject shell commands can get root.

Theo

Il 31/08/2023 15:39, Theo ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> This post refers to Linux root user that isn't normally exposed to the
>> end-users, mostly if I disable SSH service.
>>
>> My concerns are for someone with sufficient technical skills that wants
>> to enter the Linux system. The first thing he would do is finding the
>> console UART, connect/soldering a USB/UART converter, open putty and try
>> to login guessing the root password.
>>
>> The original question was for this scenario.
> 
> It depends whether the customer is your adversary or not.

It isn't... usually :-)


> If you want to prevent the customer having access, eg because hacking the
> device would cause them to get free service or similar, then preventing root
> access is a roadblock for this.  Or if the device has users whose motives
> aren't aligned with the customer (eg it's installed in a public place where
> people might tamper with it).
> 
> If the customer has bought the equipment and there is nothing the customer
> or their users can illicitly gain access to, I'd suggest leaving a default
> root password on there - it enables the customer full access to a device
> they own and have physical access to, and gives them options for extending
> the use of the device once its original purpose is ended (eg if you stop
> supporting it).  If they choose to break their device, that's their problem.
> 
> (some devices set a 'warranty void' bit if unauthorised firmware is loaded,
> to avoid having to handle warranty claims on modified devices.  Only some
> SoCs have such non-resettable 'e-fuses')

I simply don't want some "smart" users with sufficient technical skills 
would be able to understand how the device does the things it does.
For example, sniffing the code of Linux scripts or Python code of 
proprietary software.

Maybe some "users" that work in competitors.


> I'm also assuming there are no other interfaces which might render any
> password protection moot - like being able to unplug the flash storage and
> change the password in another machine, or being able to use JTAG to
> reprogram the flash chip.  If so, it may be simply a matter of difficulty -
> pulling an SD card is easy, soldering to testpoints to access JTAG lines
> less so.

If there was infinite technical knowledge and money, it would be 
impossible to protect the device. Here I would like to stop only 
"medium/low" hackers.


> One other thing, though.  If you have a fixed root password, make sure you
> ensure that regular user processes can't 'su' to root.  Otherwise any
> networked user who is able to inject shell commands can get root.

Good point. Anyway, I think it's valid if the root password isn't fixed.