🆕 Software Suggestion | Add OOSU10 #926

New Issue

jonah · 2019-05-13T08:13:30Z

KonoromiHimaries commented

2019-05-13 08:13:30 +00:00

(Migrated from github.com)

Basic Information

Name: OOSU10
Category: https://www.privacytools.io/operating-systems/#win10
URL: https://www.oo-software.com/en/shutup10

Description

O&O ShutUp10 means you have full control over which comfort functions under Windows 10 you wish to use, and you decide when the passing on of your data goes too far. Using a very simple interface, you decide how Windows 10 should respect your privacy by deciding which unwanted functions should be deactivated.

## Basic Information **Name:** OOSU10 **Category:** https://www.privacytools.io/operating-systems/#win10 **URL:** https://www.oo-software.com/en/shutup10 ## Description O&O ShutUp10 means you have full control over which comfort functions under Windows 10 you wish to use, and you decide when the passing on of your data goes too far. Using a very simple interface, you decide how Windows 10 should respect your privacy by deciding which unwanted functions should be deactivated. ![](https://www.oo-software.com/oocontent/uploads/tour/oosu10-en/01.png)

Mikaela commented

2019-05-13 08:20:37 +00:00

(Migrated from github.com)

Could you describe in your own words what is it and why it should be added?

beerisgood commented

2019-05-13 10:34:54 +00:00

(Migrated from github.com)

I'm against such tools
Better make the settings (registry + GPOs) by yourself

Also using PiHole helps a lot against tracking & telemetry

I'm against such tools Better make the settings (registry + GPOs) by yourself Also using PiHole helps a lot against tracking & telemetry

jonah commented

2019-05-13 20:20:07 +00:00

IMO we should be strongly discouraging Windows 10 use in the first place rather than provide recommendations on how to manage it, which ultimately seems like a flawed concept given that Microsoft could change/add things at any time via Windows Update in the future that breaks these protections.

👍 2 👎 1

atomGit commented

2019-05-14 21:40:46 +00:00

(Migrated from github.com)

IMO we should be strongly discouraging Windows 10

my translation...

IMO we should be strongly discouraging Windows

it's proprietary and so cannot be trusted to protect privacy... then again, there are be bigger problems than the OS (proprietary hardware and firmware)

> IMO we should be strongly discouraging Windows 10 my translation... IMO we should be strongly discouraging Windows it's proprietary and so cannot be trusted to protect privacy... then again, there are be bigger problems than the OS (proprietary hardware and firmware)

blacklight447 commented

2019-05-17 21:05:31 +00:00

(Migrated from github.com)

@atomGit Tbh, the threat of a closed source os is more dangerous then closed source hardware.

atomGit commented

2019-05-17 21:40:55 +00:00

(Migrated from github.com)

the threat of a closed source os is more dangerous then closed source hardware

i'm no authority on this stuff by any means, but i'm curious whether you'd say the same for smartphones (or any device with a cellular radio in it)?

the reason i ask is because it is my understanding that the base-band/radio firmware is a) proprietary (and there's only 2 companies making it primarily), b) full of security holes, c) has low-level access to various hardware (radio, sensors, mic, cam, keyboard) and d) shares RAM with the user facing OS ... and apparently this is true for essentially every semi-modern cellular device in at least the west if not the world

while apps can harvest all sorts of personal data, it appears that the base-band firmware (perhaps more correctly called an OS in its own right) can potentially harvest everything and there's little or nothing users can do about it since it operates at a lower level than the user OS

i've seen some Defcon talks and read a little about this issue, and i'm aware of some smaller open architecture/software projects trying to rectify this by at least isolating the base-band to its own physical memory

when i wrote that "there are be bigger problems than the OS", i generalized it because afaik essentially the same issue exists with PCs and proprietary firmware and hardware - we just witnessed the fallout of the Spectre thing (Intel CPUs) and before that the Trusted Platform Module circus, then there's the APIs that allow, for instance, a web page direct access to the video hardware/memory/whatever, built-in backdoors and on and on, which leads me to wonder if the OS really is more important than the proprietary boat it's riding in

thoughts?

> the threat of a closed source os is more dangerous then closed source hardware i'm no authority on this stuff by any means, but i'm curious whether you'd say the same for smartphones (or any device with a cellular radio in it)? the reason i ask is because it is my understanding that the base-band/radio firmware is a) proprietary (and there's only 2 companies making it primarily), b) full of security holes, c) has low-level access to various hardware (radio, sensors, mic, cam, keyboard) and d) shares RAM with the user facing OS ... and apparently this is true for essentially every semi-modern cellular device in at least the west if not the world while apps can harvest all sorts of personal data, it appears that the base-band firmware (perhaps more correctly called an OS in its own right) can potentially harvest everything and there's little or nothing users can do about it since it operates at a lower level than the user OS i've seen some Defcon talks and read a little about this issue, and i'm aware of some smaller open architecture/software projects trying to rectify this by at least isolating the base-band to its own physical memory when i wrote that "there are be bigger problems than the OS", i generalized it because afaik essentially the same issue exists with PCs and proprietary firmware and hardware - we just witnessed the fallout of the Spectre thing (Intel CPUs) and before that the Trusted Platform Module circus, then there's the APIs that allow, for instance, a web page direct access to the video hardware/memory/whatever, built-in backdoors and on and on, which leads me to wonder if the OS really is more important than the proprietary boat it's riding in thoughts?

blacklight447 commented

2019-05-17 21:49:42 +00:00

(Migrated from github.com)

Thing is, is that we hardly hear about things like baseband expliots in the wild, they are certainly possible, but those are very, very rare. But attacks on your os however are a lot more common.

atomGit commented

2019-05-17 22:36:02 +00:00

(Migrated from github.com)

well, there's what we hear and what we don't hear - we know how highly the NSA regards our phones, as well as that they certainly aren't going to be the ones sharing their exploits which we can obviously surmise exist

and we also know (i believe) that the baseband is less secure than the user-facing OS - if there are less in-the-wild exploits directed at the baseband, i would guess that's because the code isn't published, or the exploits aren't published, but that doesn't mean the NSA doesn't have access to the code - frankly i'd be more surprised if they didn't ("national security" and all)

Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks Ralf-Philipp Weinmann University of Luxembourg

abstract..

Published attacks against smartphones have concentrated
on software running on the application processor. With
numerous countermeasures like ASLR, DEP and code
signing being deployed by operating system vendors,
practical exploitation of memory corruptions on this pro-
cessor has become a time-consuming endeavor. At the
same time, the cellular baseband stack of most smart-
phones runs on a separate processor and is significantly
less hardened, if at all.

In this paper we demonstrate the risk of remotely
exploitable memory corruptions in cellular baseband
stacks. We analyze two widely deployed baseband
stacks and give exemplary cases of memory corruptions
that can be leveraged to inject and execute arbitrary code
on the baseband processor. The vulnerabilities can be
triggered over the air interface using a rogue GSM base
station, for instance using OpenBTS together with a
USRP software defined radio.

well, there's what we hear and what we don't hear - we know how highly the NSA regards our phones, as well as that they certainly aren't going to be the ones sharing their exploits which we can obviously surmise exist and we also know (i believe) that the baseband is less secure than the user-facing OS - if there are less in-the-wild exploits directed at the baseband, i would guess that's because the code isn't published, or the exploits aren't published, but that doesn't mean the NSA doesn't have access to the code - frankly i'd be more surprised if they didn't ("national security" and all) [Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks](https://www.usenix.org/system/files/conference/woot12/woot12-final24.pdf) Ralf-Philipp Weinmann University of Luxembourg abstract.. > Published attacks against smartphones have concentrated > on software running on the application processor. With > numerous countermeasures like ASLR, DEP and code > signing being deployed by operating system vendors, > practical exploitation of memory corruptions on this pro- > cessor has become a time-consuming endeavor. At the > same time, the cellular baseband stack of most smart- > phones runs on a separate processor and is significantly > less hardened, if at all. > > In this paper we demonstrate the risk of remotely > exploitable memory corruptions in cellular baseband > stacks. We analyze two widely deployed baseband > stacks and give exemplary cases of memory corruptions > that can be leveraged to inject and execute arbitrary code > on the baseband processor. The vulnerabilities can be > triggered over the air interface using a rogue GSM base > station, for instance using OpenBTS together with a > USRP software defined radio.

Peter-Easton commented

2019-05-17 23:07:22 +00:00

(Migrated from github.com)

Baseband fears were definitely the big thing, but that was before ARM processors had widespread deployment of SMMU (System Memory Management Unit) which was drafted at the turn of last decade and was specifically designed to guard against the attack you've mentioned. Provided the driver is written sanely (I've been told that Google of all people, Google open source their device drivers, and make their firmware sources available under NDA), this provides the operating system with the means to limit DMA access from a malicious device, whether that is the cellular modem, the wireless card, the SSD, your sound card, or even your GPU. Take note that this is not at all a modern thing: the Samsung Galaxy S2 has had a means to limit DMA access from a malicious modem and it was released way way back in mid-2011.

Baseband fears were definitely the big thing, but that was before ARM processors had widespread deployment of SMMU (System Memory Management Unit) which was drafted at the turn of last decade and was specifically designed to guard against the attack you've mentioned. Provided the driver is written sanely (I've been told that Google of all people, **Google** open source their device drivers, and make their firmware sources available under NDA), this provides the operating system with the means to limit DMA access from a malicious device, whether that is the cellular modem, the wireless card, the SSD, your sound card, or even your GPU. Take note that this is not at all a modern thing: the Samsung Galaxy S2 has had a means to limit DMA access from a malicious modem and it was released way way back in mid-2011.

Peter-Easton commented

2019-05-18 00:04:12 +00:00

(Migrated from github.com)

Looks like your reply made it while I was still typing mine. I looked at your paper you had posted. It is pretty old at this point and discusses baseband attacks against the iPhone 4 and HTC Dream. The HTC Dream was released to market more that a decade ago by this point and the iPhone 4 follows closely behind.

Devices have changed significantly over the past ten years.

Looks like your reply made it while I was still typing mine. I looked at your paper you had posted. It is pretty old at this point and discusses baseband attacks against the iPhone 4 and HTC Dream. The HTC Dream was released to market more that a decade ago by this point and the iPhone 4 follows closely behind. Devices have changed significantly over the past ten years.

atomGit commented

2019-05-18 03:16:25 +00:00

(Migrated from github.com)

i appreciate your comments Peter and i started to feel a little warmer at first, but when i poke around on the interwebs i find more recent things that are very worrying

this article is from 2017 and is about research by the same guy that wrote the paper referenced earlier...

Baseband Zero Day Exposes Millions of Mobile Phones to Attack | Threatpost (2017)

The researcher could not confirm how many of the specific models are impacted by the flaw. He estimated tens of millions of Honor smartphones could be vulnerable to attack by the chipset. He said 33 million Honor smartphones were shipped in third quarter of 2016 alone and that as many as 50 percent of the phones are likely using the HiSilicon Balong chipset.

Baseband vulnerability could mean undetectable, unblockable attacks on mobile phones / Boing Boing (2016) - this was patched, but i think the point is that regardless of what is done to isolate baseband memory sharing, there are still vulnerabilities

0-Days Found in iPhone X, Samsung Galaxy S9, Xiaomi Mi6 Phones | Hack News (2018)

Fluoroacetate team also hacked into the Samsung Galaxy S9 by exploiting a memory heap overflow vulnerability in the phone’s baseband component and obtaining code execution.

Tackling Cellular Vulnerabilities (2017)

these baseband processors rely on a combination of hardware and software that oftentimes is not properly tested for security problems before widespread deployment. Beginning in 2012, researchers began to explore the full breadth of security problems that exist at the baseband processor layer[iii]. Among the impacts that were identified were the ability of attackers to use nearly any cellular radio interface to attempt to run injection attacks against a handset's cellular network interface. These attacks were successful in achieving persistent changes in the target device, arbitrary code execution, and denial of service outcomes. Researchers have also outlined a wide range of other outcomes that can include persistent tracking, battery manipulation with the intent to cause physical damage/harm, and device destruction[iv].

there's a lot more scary stuff in that article

Software flaw puts mobile phones and networks at risk of complete takeover | Ars Technica (2016) - i assume this was patched, but it serves as another example of vulnerabilities even after the implementation of SMMU

The bug resides in a code library used in a wide range of telecommunication products, including radios in cell towers, routers, and switches, as well as the baseband chips in individual phones. Although exploiting the heap overflow vulnerability would require great skill and resources, attackers who managed to succeed would have the ability to execute malicious code on virtually all of those devices.

...and that's the result of less than an hour of looking at what is publicly available

given that we know a little more now about the NSA and the utterly illegal and unconstitutional bullshit these jackasses pull, i think it a super-safe bet that they've developed a whole armory full of tools that no one outside the NSA knows a damn thing about and obviously they cannot be trusted in any way shape or form

i don't particularly like peddling a lot of doom here, but i'm not going to pretend it doesn't exist either (not saying you or anyone else here is)

i appreciate your comments Peter and i started to feel a little warmer at first, but when i poke around on the interwebs i find more recent things that are very worrying this article is from 2017 and is about research by the same guy that wrote the paper referenced earlier... [Baseband Zero Day Exposes Millions of Mobile Phones to Attack | Threatpost](https://threatpost.com/baseband-zero-day-exposes-millions-of-mobile-phones-to-attack/124833/) (2017) > The researcher could not confirm how many of the specific models are impacted by the flaw. He estimated tens of millions of Honor smartphones could be vulnerable to attack by the chipset. He said 33 million Honor smartphones were shipped in third quarter of 2016 alone and that as many as 50 percent of the phones are likely using the HiSilicon Balong chipset. [Baseband vulnerability could mean undetectable, unblockable attacks on mobile phones / Boing Boing](https://boingboing.net/2016/07/20/baseband-vulnerability-could-m.html) (2016) - this was patched, but i think the point is that regardless of what is done to isolate baseband memory sharing, there are still vulnerabilities [0-Days Found in iPhone X, Samsung Galaxy S9, Xiaomi Mi6 Phones | Hack News](https://hacknews.co/vulnerabilities/20181115/0-days-found-in-iphone-x-samsung-galaxy-s9-xiaomi-mi6-phones.html) (2018) > Fluoroacetate team also hacked into the Samsung Galaxy S9 by exploiting a memory heap overflow vulnerability in the phone’s baseband component and obtaining code execution. [Tackling Cellular Vulnerabilities](https://misti.com/infosec-insider/tackling-cellular-vulnerabilities) (2017) > these baseband processors rely on a combination of hardware and software that oftentimes is not properly tested for security problems before widespread deployment. Beginning in 2012, researchers began to explore the full breadth of security problems that exist at the baseband processor layer[iii]. Among the impacts that were identified were the ability of attackers to use nearly any cellular radio interface to attempt to run injection attacks against a handset's cellular network interface. These attacks were successful in achieving persistent changes in the target device, arbitrary code execution, and denial of service outcomes. Researchers have also outlined a wide range of other outcomes that can include persistent tracking, battery manipulation with the intent to cause physical damage/harm, and device destruction[iv]. there's a lot more scary stuff in that article [Software flaw puts mobile phones and networks at risk of complete takeover | Ars Technica](https://arstechnica.com/information-technology/2016/07/software-flaw-puts-mobile-phones-and-networks-at-risk-of-complete-takeover/) (2016) - i assume this was patched, but it serves as another example of vulnerabilities even after the implementation of SMMU > The bug resides in a code library used in a wide range of telecommunication products, including radios in cell towers, routers, and switches, as well as the baseband chips in individual phones. Although exploiting the heap overflow vulnerability would require great skill and resources, attackers who managed to succeed would have the ability to execute malicious code on virtually all of those devices. ...and that's the result of less than an hour of looking at what is _publicly_ available given that we know a little more now about the NSA and the utterly illegal and unconstitutional bullshit these jackasses pull, i think it a super-safe bet that they've developed a whole armory full of tools that no one outside the NSA knows a damn thing about and obviously they cannot be trusted in any way shape or form i don't particularly like peddling a lot of doom here, but i'm not going to pretend it doesn't exist either (not saying you or anyone else here is)

quantumpacket commented

2019-05-18 17:06:31 +00:00

(Migrated from github.com)

I use this tool on my Windows VM just to shutdown/disable unnecessary features to speed up the system. As for privacy well the software itself says it needs to be run after each update or boot as Windows will revert things. So far when you boot Windows re-enables automatic updates. That being the case and the fact both are closed source it's not really a proper solution for privacy.

dngray commented

2020-10-13 16:03:33 +00:00

(Migrated from github.com)

I want this reevaluated, along with https://github.com/privacytools/privacytools.io/issues/1624 as a part of the updated Windows 10 page.

The I'm not a fan of using windows firewalls to disable telemetry (what W10Privacy does, https://github.com/privacytools/privacytools.io/issues/938) based features when there are ways within windows to do this that involve disabling the components directly.

I have not tested this tool myself, but am told that it can disable telemetry in ways similar to: https://docs.microsoft.com/en-us/windows/privacy/manage-connections-from-windows-operating-system-components-to-microsoft-services

We have given exemptions in some cases to things being proprietary when no other alternative exists. Pragmatically I'm not really bothered by this tool being licensed under a proprietary license, when Windows itself is anyway.

Additionally since Windows 10 build 2004 Cortana can actually be removed ie Get-AppxPackage -allusers Microsoft.549981C3F5F10 | Remove-AppxPackage

On the argument of "not using windows" this might be all well and good, but we should still maintain a up to date page with best practices for maintaining privacy on the Windows platform regardless. With some usecases it is unavoidable.

I want this reevaluated, along with https://github.com/privacytools/privacytools.io/issues/1624 as a part of the [updated Windows 10 page](https://www.privacytools.io/operating-systems/#win10). The I'm not a fan of using windows firewalls to disable telemetry (what W10Privacy does, https://github.com/privacytools/privacytools.io/issues/938) based features when there are ways within windows to do this that involve disabling the components directly. I have not tested this tool myself, but am told that it *can* disable telemetry in ways similar to: https://docs.microsoft.com/en-us/windows/privacy/manage-connections-from-windows-operating-system-components-to-microsoft-services We have given exemptions in some cases to things being proprietary when no other alternative exists. Pragmatically I'm not really bothered by this tool being licensed under a proprietary license, when Windows itself is anyway. Additionally since Windows 10 build 2004 Cortana can actually be removed ie `Get-AppxPackage -allusers Microsoft.549981C3F5F10 | Remove-AppxPackage` On the argument of "not using windows" this might be all well and good, but we should still maintain a up to date page with best practices for maintaining privacy on the Windows platform regardless. With some usecases it is unavoidable.

👍 1

This repo is archived. You cannot comment on issues.