Bare to no security on live installer?

It came up as part of an other thread that lubuntu installer is doing a certain amount of network activity during installation: geolocation to sniff out hints for keybd and timezone, calling https://ipapi.co/json and a few others.

Is having any network activity originating on such a system really wise considering that you can do sudo su and the user ( sudo ) pw is blank.

The low security set up is handy for a low level off-line utility disc but how sound is this if the installer is going to start initiating outgoing traffic and wants a live connection?

At first view this looks more than a little crazy.

I don’t see the risk. When using a ‘live’ environment, there is no data available on the system (except for the software on the ISO which is public anyway), you’ll have rebooted and if I was worried about whatever was in RAM before the reboot, I’d have cleansed [my ram] before I booted the ISO.

If I mount data, I initiate it so it’s my choice (in my case it requires adding packages anyway first).

As for geolocation stuff - that is the acceptable/industry norm today. If I don’t like it, or want to stop it I won’t allow it. A ‘live’ system cannot access internet using wifi until I provide access, ethernet is equally easy to stop (and if I’m worried I’d use a machine on an internal network only or restricted-vlan)

Most people I believe (by the popular choices of phones, OS & hardware used) accept this being the industry-standard, those of us who do care about our privacy have opted for something different, or instituted workarounds that give us back some of the security industry-norms have taken away.

All opinions expressed here, are of course my own!

Correct me if I’m wrong, but doesn’t Ubiquity (the installer for all the other Ubuntu flavors) suffer the same concerns?

2 Likes

So to summarise your position you seem to be saying, yes it is insecure but it does not expose any important risk. Secondly, it’s “normal”, thus in some way OK. ( I hope I’m not mischaracterising that, I’m not trying to ).

One of the main reasons I use Linux is because it is intrinsically more secure than Windows. One of the key reasons for that is the separation of root privileges.

If I mount data, I initiate it …

I think the security point is that if you expose a system with open root access to a network, you are no longer the only one can initiate things, in fact anything. Since the main job here is to install a clean, virgin system, it seems to be worst time to expose yourself to a security problem. This should 100% safe, in order to know that when you reboot you are certain to have a clean, pristine system.

Most people … accept this

Most people have no idea what they are doing, nor of the consequences and get mugged. I don’t think the " one million lemmings can’t be wrong" is a very convincing security argument.

This is not the kind of area where I expect to need investigate the security risks implemented by developers and start inventing work arounds. I expect developers to be of a higher level of competence than I am and to make installation fully secure out of the box, by default.

I would summarise this discussion in three points:

  1. Is there security risk? It certainly looks that way but I’m open to concrete arguments to the contrary.
  2. Is there an over riding reason for this being done.? If it is just auto-filling timezone and keydb, that really does not carry much weight.
  3. Other OS providers ensure that they remain in control of user’s hardware. In reality they “own” it , users use it. “Most people” are dumb and will blindly sign legal contracts and accept EULAs without reading them, we should not align to lowest expectations when making security choices for the distro because “it’s the norm”.

Sadly, that would not surprise me in the least. IMO *buntu is flying very close to the wind with this whole sudo su pradigm and has already caused some messy outcomes ( I think Mint was the most recent perpetrator of systemic stupidity in trying emulate Window’s “ease of use” and ended up providing a hackable Linux distro).

Most of the loopholes have been closed on this but it seems inherently risky to me.

The nice thing is that you have the choice to do this better having opted for a different installer. :wink:

Huh? :face_with_raised_eyebrow:

I’m not here to start a debate/argument, but I’d like to see proof of this in some form where it doesn’t already exist for other distros that do exactly the same as Linux Mint (ease-of-use, modern UI) and for which also base themselves on Ubuntu. You elude to other distros doing the same, but I would like evidence where somehow Mint is more hackable than any single other distro out there where the setup is almost identical.

Again, not here to argue. I personally take my privacy and security very seriously. I appreciate it when things that need to be called out are called out, because people deserve to know. :slight_smile:

In this case, I don’t see Mint any more hackable than Ubuntu, or Debian for that matter. If the stuff that Mint—in particular—chooses to run with by default on their distro somehow makes them more vulnerable than say stock Debian (maybe), then the same argument can be made for distros like Kubuntu, Pop!_OS, Zorin, PureOS, etc. Trinity DE is the most successful take on legacy Windows UI when I used it on Q4OS. Would that suddenly make them more hackable?

Help me understand why Mint is doing so bad?

sorry, it seems it was their server which got hacked and someone implanted a modified download with a backdoor, so I was mistaken about this being the OS ( as designed ) being hackable.
https://blog.linuxmint.com/?p=2994

However, in searching that I found this recent security issue

“The vulnerability in question is a sudo security policy bypass issue that could allow a malicious user or a program to execute arbitrary commands as root on a targeted Linux system even when the “sudoers configuration” explicitly disallows the root access.”

https://www.sudo.ws/alerts/minus_1_uid.html

Only sudoers entries where the ALL keyword is present in the Runas specifier are affected.

*unbuntu distros have :
%sudo ALL=(ALL) ALL

I replied to the above because I was ( somewhat ) incorrect about the Mint LInux issue, however, can we keep this focused on the question of having sudo ALL=(ALL) ALL and a null password on the install ISO image.

Since the installer silently grabs any connection it can find, activates it and initiates outgoing traffic which additionally opens a hole in any upstream firewall, this leaves the system wide open to any fortuitous attacker.

For the tiny convenience it provides in setting the ( presumed ) locale the user wants, this seems an extreme risk for a trivial convenience.

If the installer said to the user : there is zero protection on your computer system right now, would you like to open up your computer to the internet? I’d hope that most people would say : no way!

Not only does this seem unwise, it really should not be done without the user’s knowledge and express permission.

1 Like

I’m totally in for criticizing sudo policy, so long as we ring in all the prime implementers (including Mint).

Still don’t see how Linux Mint nor any other distro is more hackable just because of this, however…

Sadly , I think the sudo su thing is cast in stone at this stage, though I think most of the exploits have been detected and fixed by now, it just seems a precarious situation which is just waiting for someone to discover the next chink in the armor.

The main issue with the installer is that this is sudo su system with a null password which means there is zero security. As I said above this is fine for a utility disc but it should not get anywhere near a live internet connection.

You seem to miss the point that if the system is insecure ANYONE can sudo without a password and install a trojan or do whatever they please. I’m surprised you fail to realise the implications.

Is no one concerned about this?

I did see it, am aware of it, but sorry I don’t have anything to say (also I’m not qualified enough).

Even if Lubuntu is perfectly secure and impossible to do anything malicious with, if a user can boot a ‘live’ system they’ll boot another GNU/Linux distro (or BSD maybe) and use that for their malicious purposes. Booting something ‘live’ is a security concern yes.

Backup and security strategies have to be built on the assumption that every connection is potentially malicious, users could have unexpected or faked credentials…

My own personal backup strategy is built assuming I’m the idiot that deletes two sets of my backups & main arrays due to some mis-typed rm. I have jobs that generate reports of ‘changed’ files (thinking trojan), but I know I could miss changes if I also worked in that directory and thus only quickly skimmed it. Given long enough it could pollute all my backups. I can’t cover everything, we all have cost restraints, concerns we consider too minor, and we just can’t spend the effort required to mitigate them any further.

Firstly, forgive a multipart response pulled from all over the thread. This is kind of necessary.
I come from an IT Security centric background so let me give you my two-cents with the Security hat on.

The Live Installer image is good as a utility disk. It is not designed to be a replacement for a full installation. It also is required to reach out for updates during the installation process if you choose to install restricted extras or software selections that aren’t on the image. Network access controls for average systems are fairly easy to implement even in a Live environment - just disable networking if you don’t want it reaching out for any of those things. The Live environment having networking is also critical for another reason though - if you are in the process of repairing an installation or such, you may need extra utilities and tools. This allows you to obtain those tools to do what you need to do.

Now onto your specific concerns.

Explained above in my little tidbit of information. But as the Live installer is designed to allow easy installation and utility usage and temporary access to things without persistent storage by default, the security risk there is negligible since anything ‘downloaded’ malicious would get erased on a reboot.

This said…

… you are implying that ‘open network access’ is bidirectional. The Live installers have no remote mechanisms to accept remote connections by default - no OpenSSH server enabled, no FTP, no Telnet, etc. so the actual network ‘risk’ here is limited by the scope of what’s actually enabled on the drive. Secondly, the installers require network access, and aren’t designed to be more than a utility or installation disk, and you can shut off network access pretty easily. Which again mitigates the risk.

… and yes, the OS has no protections against this type of attack, but that’s because that’s outside the purview of the OS’ control, and anyone going to such websites are going to have to have a level of accountability and ‘accepted risk’ by simply browsing to a site. This said, the Installers don’t reach out to ‘random sites’ in the nature you’re implying.

… wrong, it only does this on an Ethernet connection, it won’t autoconnect to any arbitrary Wireless connection, and only grabs DHCP on Ethernet.

… which still requires the user to do something first which activates the exploit. Which because the users are not as in tune with the environment of Security as we’d like can happen, but because the installer isn’t persistent, that’s a non-issue typically.

As stated here by guiverc, this is a user change that is approved by a given user to mount the data partition, etc. And if the issue is a case where you’re using the Live device as a temporary environment, you the user accept by default (and simply by use of software) any security or liability issues that come from it. Because this is a user required thing, however, this is a non-issue since most cases users aren’t mounting other partitions in a way that’d be malicious.

Again, you’re implying that the network risk is openly bidirectional, which it’s not unless the User initiates something that connects to a malicious connection source. Because a default Live environment does not have any network services listening for connections and responding in the nature that an attack is naturally a risk, the risk of this is mitigated because those vulnerable services necessary to execute a command are limited.

Even within the scope of the Live environment, though, most of those ‘vulnerable scripts’ and ‘vulnerable sites’ which a user can connect to to initiate an exploit on their system target the root filesystem, which is loaded from SquashFS into a ramdisk so that when you reboot it won’t still have the data, because the squashfs is loaded readonly into the ramdisk. As such, that risk is mitigated by this fact.

Further, consider that your other argument of…

… applies ONLY to the Live environment, and the prime rule of Security is “If anyone has physical access to the machine, you are already screwed.” Physical direct access to load such an insecure environment is already the prime security attack vector - just running the Live environment itself whether it being you, me, or someone else is already a violation of the initial Security concerns regarding direct machine physical access, so if someone is already at that point you’re already hosed because a malicious threat actor would first have to load the insecure system on the system, and to do that they need physical access or will have to already breach an environment to get to the point they can load the insecure system up. At which point you’ve already got a larger security concern at play here than “The live installer is not secure or hardened.”

And as guiverc says here, this is the assumption of risk on the end user loading something as ‘live’. This said, as I said before, a Live environment is not designed to be run all the time, it’s designed to be used for a specific case (ala Kali Linux or for Ubuntu installation) or as a temporary utility disk (ala booting into the Live environment to recover data specifically or to repair a disk or a boot environment with boot-repair).

To make a Live environment as secure as a normal installation would defeat the purpose of the Installer image being that. This said, if you’re really that concerned about this, you should be using the Minimal ISO which has no Live environment of that nature. It does, however, require Network access to actually download the various packages it needs to install an Lubuntu environment to disk, so you will still need Network access at some point in the process of installation.

3 Likes

Firstly thanks for a thoughtful and detailed reply. There are certain details which reassure me that it it’s not as bad as it might be. That said:

Lubu:

if the system is insecure ANYONE can sudo without a password and install a trojan or do whatever they please

teward:

… applies ONLY to the Live environment, and the prime rule of Security is “If anyone has physical access to the machine, you are already screwed.”

No, I was not talking about physical access but that if , by any means, someone gains user level access to the live connection they can escalate to root without even needing the user pw since it is null ( and one can be sure that will be tried ).

permission escalation is regarded as a serious security breach on most distros. *buntu seem to regard it as a feature.

The defense of the present situation seems to be :

  1. it does not last long. How long to you spend looking for a dropped bar of soap in the prison showers before it becomes a risk ?
  2. it’s all in RAM, so it doesn’t matter. Anyone capable of intruding is probably smart enough to work that out as well ( or his script will test what is running ) and will fdisk -l to see what else is around.
  3. the only thing exposed is what the live user has chosen to mount, it’s on his head. See 2.
  4. … which still requires the user to do something first which activates the exploit. Social engineering is a common and successful exploit, it is not the only security issue. I’m rather surprised that a security guy makes that mistake.
  5. The Live environment having networking is also critical for another reason though - if you are in the process of repairing an installation or such, you may need extra utilities and tools. If I chose to activate the network connection on a sudo su ( null p/w ) system you can point and laugh. Doing so behind my back is not a good way to go about it.
    5b… and only grabs DHCP on Ethernet. Well you are only a virgin one. I really don’t see how this helps.
  6. just disable networking if you don’t want it reaching out for any of those things. Well first I need to know that my “installer” is going surreptitiously connect itself without telling me. Only if I’m paranoid and disconnect before running it , does it have the good manners to tell me it wants one.
  7. It also is required to reach out for updates during the installation process if you choose to install restricted extras or software selections that aren’t on the image. I’m not sure this is talking about lubuntu. I don’t recall getting any choices about extras. I appreciate the brevity of just installing a basic system and then going for additional packages I need to install later. Once I have a secure system running.

Which is an atypical case. Again, you’re looking for issues where the default case of use for a Live environment is not subject to these uses.

Whether this is “Joe Randomer” or myself or Simon Quigley or anyone else, the core point of a Live instance is that it’s not being used for anything other than its intention. If JOe Randomer is booting into a Live instance to do regular every day activities as well as mounting partitions then that is no more or less secure than an on-disk install, sudo access aside, because of the plethora of risks such as malware or trojan horses you’ve identified not having that kind of elevated access OR requiring user intervention to install. Which again, this is a live system, not a full install.

So far, the issues we’ve addressed aside, it sounds more like you’re looking for "Issues which Don’t Typically Exist Even With Joe Randomer the Normal User Guy"™. The Average User isn’t going to be using the Live environment for their daily use cases, so that is not a typical issue here, and at that point we start ending up in ‘edge cases’ that don’t apply to 99% of the accepted uses of the drive by 99% of the users of it. Those power users using the drive however will already be aware of the ‘risks’ associated with it and those deviations from the ‘typical use case’ of the disk will already be taking steps to reduce their risk by only using trusted sites, sources of info, etc. and not just randomly connecting to ${NETWORK} as you’ve suggested would happen.

And I never said social engineering is the only risk - nor was I referencing Social Engineering but any of the thousands of malvertising cases available from ${INSERT_ADVERTISEMENTS_FROM_AD_SERVICE_HERE} on ${INSERT_SITE_HERE}, but in 99% of cases, the exploits you’ve thought of all require some user interactivity to initiate - browse to a malicious site that exploits these holes in the system, browse to a website that has ads of this nature embedded, install malicious software, etc. usually ALL require some user access to implement, even if they are simply “opening the web browser”.

With no other openly-attackable exploit vectors except that of physical access or neighbor-on-same-network type attacks (which still wouldn’t have much of an attack surface to go after) the remaining arguments for 90% of the remaining cases you’ve come up with are not typical cases to run into, even with Joe Randomer involved.

This said, Lubuntu inherits a lot of the setup environment stuff for security concerns from the generic environment to begin with, so these issues are more than just an Lubuntu concern, it’s how the base livefs are created and structured. And in most cases people using Live environment as Joe Randomer are not using it as a production environment, and using it instead to facilitate installation or as a boot-repair mechanism.

You still seem to be under the impression that physical control ( which I never mentioned ) or dumb user clicking on obviously dodgy idiot-bail ( which I never mentioned ) whilst foolishly doing random browsing with his insecure live system are the only security risks which exist.

You do not seem to address a single one of the 7 points I outlined above.

it sounds more like you’re looking for "Issues which Don’t Typically Exist

Most systems do not get compromised, so you could say any attack getting into a system is one of those “issues which Don’t Typically Exist”.

Good computer security practice is not based on saying “it probably won’t happen to me, I only take small risks, and only with other people’s computers ( but it’s alright because I don’t tell them anyway)” .

In most cases I think it is OK to use the default settings and clone from a Lubuntu iso file to a USB pendrive, but if you want to make a truly live-only drive with Lubuntu 19.10 and future versions, you should use the boot option nopersistent. See the following link.

1 Like

FYI we kinda inherit the sudoers setup you’re referring to from Debian’s live images, digging further over the past few days this kind of originates from Debian in terms of ‘basic setup concerns’.

But as was stated, though, by me, a Live environment is not set up securely because of its intended use case, if you want a live persistent install you should install with persistence then customize it accordingly.

Equally insecure security would be a-la Kali Live, in which we would disable root account by default, but then provide a password for the user which would be weak and publicly available, which is equally poor because any of these malicious threat actors would be able to pretty quickly identify a Live environment and then use the publicly shared ‘crap’ credentials.

I think the core issue here is you’re saying the Lubuntu Live Environment is by default insecure, which is a given because it’s not designed to be used in place of an actual system, intentional or not. It was not designed to be used in place of a system, if you say there’s security issues like you do propose solutions rather than countering information being shared with you or provided to you.

3 Likes