Hi gang,
In our pups and ddogs, whether they have been started up or not, "Automounting" of attached devices does not occur until we either specify it and/or click on it (a USB thumbdrive, USB harddrive, SD card slot, etc, etc).
General Question is this:
Can a virus be passed to your Pup/Ddog/general Linux OS from something that was not automounted?
What confuses me is "How" does the OS even know a device is there "to be mounted" if it hasn't already been communicated with by the OS? It would seem it doesn't even need to be "mounted" since the OS is already communicating with it somehow to let you know it is there to be "mounted". Thus, a virus will hop onto/into your OS no matter if you did and/or didn't mount the device, yes?
Would appreciate any clarity from those in the know here....recently sat in a large European blackhat/whitehat conference where the argument was made that Linux (for years) has not been clear on what happens when devices are not yet "mounted" but they are plugged into the OS (or left plugged-in when the OS boots---they did both scenarios).
They clearly, convincingly (and spookily) showed how any virus can hop right over to any Linux OS without a plugged-in device ever being mounted.
I had always thought plugging something in (or leaving it plugged in knowing your OS would not automount it at boot) meant that even if the plugged-in device was infected, it could pass nothing to your OS because you did not mount it yet.
No 'automount' yet still passes infection?
Mounting is just inserting a filesystem into at a certain point in the current tree. Low level commands can alternatively be used instead of the OS's mount code. Code on the removable device however can't run a mount action, requires code within the system to do that.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
The OS has nothing to do with detecting the device in the first place.
That is down to the BIOS and the hardware.
If the infection is taking place at that level, which many newer ones do, then you will be infected no matter what OS you are using.
At the other end of the scale many viruses infect browsers and again the OS behind them is irrelevant.
That is down to the BIOS and the hardware.
If the infection is taking place at that level, which many newer ones do, then you will be infected no matter what OS you are using.
At the other end of the scale many viruses infect browsers and again the OS behind them is irrelevant.
"Just think of it as leaving early to avoid the rush" - T Pratchett
Software errors/flaws are called bugs. Bugs led to the term virus being used, in reflection of medical terms. Bugs are something that the program/code wasn't intended to do and where those errors can be exploited can lead to the bug being considered a security vulnerability. That's just one form of security issue, others include 'infecting' things i.e. code specifically written and hidden ... to potentially exploit/breach security/damage/steal. Browser infection i.e. adding or hiding code to do something for the benefit of a dark-hacker are no different to infecting any other program/code. To do that however either the virus has to be pre-installed at source (hence you should only ever obtain programs from known/trusted sources/suppliers), or a virus can be added typically via bugs. Not much can be done against that, if developers release what they believe to be good/bug free code, but bugs are present, then those bugs could potentially be exploited. Basically just updating to the latest releases conceptually reduces that risk (however often new releases can contain even more bugs). Typically to exploit such flaws however the hacker needs to gain access one way or another and a browser being a front line external facing/using program is more likely to be the means by which undesired access/exploit was achieved. Plugging in a device that opens up firmware code running is another means i.e. the USB method that this thread addresses.Burn_IT wrote:At the other end of the scale many viruses infect browsers and again the OS behind them is irrelevant.
Typically achieving privilege elevation to root/admin is considered as being game over, full/total control to do anything, including installing firmware/other sub-OS level doors such that a system/local network is considered as being 'owned'. Running as root makes such game over potential much more likely than if running as a restricted user.
Whilst external to internal access is often tightly controlled, outbound requests and their replies are much less validated. Commonly a virus will simply be a outward request to the hackers system asking for a reply, and where that reply is run as a program before another request is made. Many of those runs will typically fail, but when a winning case is found then the replies can be refined to do more 'successful' things.
Bugs and viruses are not just files/firmware/program code, they can also be ram based. Tight file/folder security can be lost if copies in memory can be compromised. Compromising memory can subsequently relatively quickly open up compromising the entire system/lan/firmware.
Typically dark-hats are ahead of the curve, white-hats lag. Whilst security products often attempt to suggest their products make you safe generally that is wrong. Security is a process, not a product, and its better to consider any system as being unsafe/insecure than to assume it is secure. Accepting the potential insecurity has you better positioned towards minimising the risks/raising the bar. Its a trade off however, risk and usability are inversely correlated. At the extremes the most secure system is unsable. The least secure might be highly usable/fast. Generally most accept being somewhere midway between the two. I use OpenBSD for instance and accept that it can be slower than Linux (often however there is no noticeable difference, its only in certain areas when a difference is apparent). Barry's EasyOS is a good compromise, Barry's designing/implementing methods that raise the bar whilst not noticeably impacting operational speed/usability.
Just some of the things that OpenBSD do to raise the bar is to randomise the kernel, so the code doesn't sit in the exact same memory locations each time its booted. They randomise PID's and fileid's, divide and encrypt swap space, restrict certain memory to be W xor X (write exclusive or execute) - so that hacks that attempt to write code into memory and then execute that code hit a wall. OpenBSD have a process/method they call Pledge, where programs have boundaries set as to what they can do/access, any deviation outside of that being considered a potential threat/risk. The next release of OpenBSD includes unveil, that restricts access to filesystem areas on a process by process basis. OBSD runs nightly/weekly/monthly security checks that flag up potential intrusion detection. Personally in addition to that I also run regular checksum validations against all bin's, libs, sbin's and /etc as a further intrusion detection i.e. if a trojan might have been installed into any of those files/folders. Browser and web server are restricted, in effect run inside controls zones. And of course browser and most things don't run as root (OBSD even use a more secure version of X that has root running/owning just a very limited/small amount of control/processing, the rest is passed on to restricted ownership/userid's). OBSD further keeps tight reigns on memory utilisation/randomisation and cleansing. Its also released on a 'secure by default' basis, i.e. is pretty much default pre-configured using sensible default settings. Again not invulnerable, but a much higher bar for dark-hats to hurdle than many of the alternatives. Blobs, supplied binary code that cannot be audited are a concern under Linux, as they could contain code/functions that circumvent security. OBSD do not tolerate any Blobs - which does mean that the hardware that OBSD works with is less than compared to Linux. Linux prioritises usability and speed over security. For me that is not a issue as my current hardware works well with OBSD and my intent is that any future hardware that I obtain will also be selected such that it works well with OBSD.
In respect to a infected USB however and again OBSD is no more/less invulnerable as its a firmware/BIOS issue, not a OS issue. More a case of security process i.e. down to you to not to plug in anything you are not comfortable with - trust the supplier/source in a similar vein to trusting of program supplier/source. If you're blasé about which repos you use, or source of attached removable devices etc. then you're more inclined to be owned over that of being particular about sources. I've moved away from multi-booting for that reason. BIOS/firmware/OS etc. that I trust. Formerly I was using Debian and their main repos only - until I identified over 1700 potential security issues that prompted me to move over to OBSD.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]
Linux can be targeted by rootkits.
Storage devices (disks etc) are accessible to the OS long before the user mounts them or accesses them with DD or gparted etc.
ie: your system code can be altered without you knowing it - if that code is stored on a write-enabled device (even if you do not mount that device).
The only protection for your code is for it to be read-only
The only protection for your stored personal data is to have it disconnected from your system during any session that exposes you to incoming code (from browser etc).
Obviously that is problematic if you want to use that personal data or personal storage while online.
Basically:
- never save any info into your operating system from online sessions. Each boot must be from known good code uncontaminated by contact with previous online sessions. Savefiles are a major risk.
- never have your storage disks connected to your system during online sessions
Storage devices (disks etc) are accessible to the OS long before the user mounts them or accesses them with DD or gparted etc.
ie: your system code can be altered without you knowing it - if that code is stored on a write-enabled device (even if you do not mount that device).
The only protection for your code is for it to be read-only
The only protection for your stored personal data is to have it disconnected from your system during any session that exposes you to incoming code (from browser etc).
Obviously that is problematic if you want to use that personal data or personal storage while online.
Basically:
- never save any info into your operating system from online sessions. Each boot must be from known good code uncontaminated by contact with previous online sessions. Savefiles are a major risk.
- never have your storage disks connected to your system during online sessions