- cypherpunks - lists.cpunks.org

[dos@dosowisko.net: Re: [Tinkerphones] "We don't control our lives" - smartphones - tinkerphones - debian on smartphones]
by Zenaan Harkness 30 Jul '20

30 Jul '20

fyi ----- Forwarded message from Sebastian Krzyszkowiak <dos(a)dosowisko.net> ----- From: Sebastian Krzyszkowiak <dos(a)dosowisko.net> To: Tinkerphones Community <community(a)tinkerphones.org> Cc: CypherPunks <cypherpunks(a)lists.cpunks.org> Reply-To: Tinkerphones Community <community(a)tinkerphones.org> Date: Wed, 29 Jul 2020 18:46:09 +0200 Subject: Re: [Tinkerphones] "We don't control our lives" - smartphones - tinkerphones - debian on smartphones List-Id: Tinkerphones Community <community.tinkerphones.org> Hi, just for the record - the Debian wiki pages you have linked to are rather outdated and not really relevant anymore. Current efforts around running Debian on mobile phones (such as Librem 5 and PinePhone) are concentrated around DebianOnMobile team, which includes people working on PureOS and Mobian pushing their stuff to Debian upstream. Recent weeks brought massive progress and Purism's Phosh environment is now on its way to Debian Testing. See: https://wiki.debian.org/DebianEvents/internet/2020/MiniDebConfOnline?action… https://salsa.debian.org/DebianOnMobile-team https://lists.debian.org/debian-mobile/2020/05/msg00000.html https://qa.debian.org/developer.php?login=debian-on-mobile-maintainers@alio… https://matrix.to/#/#mobile-debian:matrix.org Cheers, dos On 7/29/20, Zenaan Harkness <zen(a)freedbms.net> wrote: > With respect to "smart" phones, it can be reasonably claimed that we don't > control our lives. > > At the hardware level, the baseband (radio) computer in almost all cases has > access to RAM, thus access to your passwords and keys for any open wallet or > encrypted filesystem, etc. > > Notwithstanding, we owe it to ourselves to run an operating system which at > least does not deny to us, our right to install and run any software of our > choosing. > > The average Android and iOS Apple phone, is a strict walled garden into > which only authorised software may be installed. > > Software "Apps" which are not authorised (or have been banned) by either > Google or Apple respectively, are not available in the respective "Play > Store". > > This is abhorrent, a centralisation of power, a blatant censorship vector, > financially burdensome to those of meagre means, and fundamentally unethical > in principle wrt the suppression of the basic rights of the end user (refer > to Richard Stallman's GNU General Public License for details of fundamental > human rights in relation to software/ apps/ computing). > > > Totally random scenario/ example: > > Some rando punk decides Tor needs improvement, and works diligently for zero > pay and little gratitude to bring say (random examples) chaff and UDP > transport layer features to Tor. > > After horrific bugs and even worse security problems in the code are > identified / repaired by tragically paranoid other punks, NeoTor takes off, > thwarting the deep state's end to end onion route monitoring network, and so > an urgent order is made upon Google to cease and decist from distributing > such nefarious software. > > Google of course complies immediately, and almost all users go back to using > old Tor. > > > The stranglehold Google and Apple have on not only limiting the average user > to approved software only, but to enforce total transparency upon all > developers to idetify themselves with 100 points of ID just to TEST their > software, and to pay some fiats for the priviledge whilst they're at it, is > ... a little less than satisfactory. > > Having experienced the pain of an Android phone, even after unlocking still > being locked into the garden and offered only "Google" or "XiaoMi" when > saving every contact (and never "local storage only"), and the pain of > finding and installing a rooted OS (_how_ many dozen options? I _still_ have > to choose Google or XiaoMi if I want to backup my contact list? there's > really _no_ easy option to just dump it to my laptop with an ad hoc > wireless?) > > ... it is evident I would be MORE than happy to pay $50 to make this pain go > away by having someone at my local computer club back up my address book and > install Debian on my phone. > > What we need is Debian on the phone. > > And we need this to be super easy for the average geek to install, and > thousands of average geeks need to start getting these donations to install > Debian on Android phones. Given how painful it is for someone supposedly > "technically literate", this ought be a fantastic business opportunity. > > > So Debian on mobile phones? It's possible. > > What is needed is a geek-able process whereby the "CyanogenMod" mobile phone > operating systems are split into an absolute minimal "bootloader + kernel + > drivers etc" for a specific device, and the operating system is a separate > install on top of that, and for those who care, Debian as the OS. > > > https://wiki.debian.org/Mobile > > http://www.tinkerphones.org/ > > https://lists.goldelico.com/mailman/listinfo.cgi/community > > https://lists.debian.org/debian-mobile/ > > https://lists.debian.org/debian-embedded/ > > https://lists.debian.org/debian-arm/ > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/android-tools-devel > > https://wiki.debian.org/DebianOnHandhelds > > _______________________________________________ > Community mailing list > Community(a)tinkerphones.org > http://lists.goldelico.com/mailman/listinfo.cgi/community > http://www.tinkerphones.org > -- Sebastian Krzyszkowiak dos _______________________________________________ Community mailing list Community(a)tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org ----- End forwarded message -----

2 1

The Tech Giants Are Dangerous, and Congress Knows It
by jim bell 30 Jul '20

30 Jul '20

The Tech Giants Are Dangerous, and Congress Knows It https://a.msn.com/r/2/BB17lkPH?m=en-us&referrerID=InAppShare Jim Bell's comment:I detest both Congress AND "The Tech Giants".

1 0

Re: www.Tesmanian.com: FCC approves the operation of 'Starlink Router' for SpaceX's internet
by Punk-BatSoup-Stasi 2.0 30 Jul '20

30 Jul '20

On Thu, 30 Jul 2020 11:51:29 +1000 jamesd(a)echeque.com wrote: > On 2020-07-17 05:37, Punk-BatSoup-Stasi 2.0 wrote: > > wow - infinitely hilarious. Hey Jim are you posting that as an example of infinitely idiotic US nazi propaganda? Or do you happen to believe, like a good randroid, that musk is a poor oppressed capitalist fighting for 'freedom'? > > Nah, he is fighting for freedom for smart, wealthy people to get away to > mars. mwahaha! Thanks James. I knew you could outdo your namesake Mr. Bell. This 'mars colonization' thing is infinitely idiotic raised to the cube. Of course, musk's purpose here is to get as much subsidies as possible so 'mars colonization' might be an excuse as good as any other. But in the minds of your typical techno-fascist retards, the heroic cunts are going to waste trillions in 'colonizing' a completely dead desert...in another planet! Yeah, right. Idiocy can't get any more idiotic. > China will be able to censor starlink connections inside China, and > Russia will be able to censor starlink connections inside Russia, but > they are going to have to cut a deal with Musk, and Egypt, Iran, and > probably India are not going to be able to censor. so what does that mean in libertarian terms? Oh wait, libertarianism is something completely beyond your understanding. Disregard my question.

1 0

Asaange
by таракан 30 Jul '20

30 Jul '20

Just watched 10 secs of the interview with Assange's .. Partner The former 'partner' is her lawyer and in front of what? Even if *she* makes him going out of jail it's just female understanding each others... Not like a helicopter extraction and shoot ... shoot .. Shoot like men do :-) oooo that fucking female world... sometimes I think Dombass not good enough, I get asylum in chechenya ... if you think I just kidding... I really mean it and I really live there we LIVE a FUCKIN**** FE MALE DOMinATED WORLD ---------- CRYPTOANALYZER ---------- Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 16

Decrypt: US government is getting serious about tracking crypto
by jim bell 30 Jul '20

30 Jul '20

Decrypt: US government is getting serious about tracking crypto. https://decrypt.co/?p=35585

3 2

F**ck ALL the non-Cypherpunks
by таракан 30 Jul '20

30 Jul '20

So far only Mr Jim bell is cypherpunk, the rest you are just … punks right ?

6 7

POWERFUL GROUPS SUCH AS GOVERNMENTS AND CORPORATIONS MUST NEVER HARM ANYONE AT ALL
by Karl 30 Jul '20

30 Jul '20

Businesses, governments, militaries, and secretly- or centrally- managed societies MUST refocus around nurturing caring, gentle wisdom within all communities, _over_profit_, _over_power_, _over_order_, _over_victory_, _over_secrecy_, _in_all_possible_ways_. _These_groups_must_never_harm_at_all_, neither directly nor indirectly, nor provide nor allow for any other such groups to. These groups have exerted genocide on most of the people of this planet, violently mutilating us, cripplingly poisoning us, even intentionally exerting destruction of our minds, hearts, brains, bodies, all the while saying that they are aiding or helping us, when in actuality they are planning to and have been actively and rapidly enslaving us to their systems. HARM MUST END, HARM OF INDIVIDUAL "HARMERS" EQUALLY SO. We are one body, our species, on this planet. We will not break apart.

1 0

Fuck the set of all...
by Douglas Lucas 29 Jul '20

29 Jul '20

A symphony in 4 parts Part the First, angry and intentionally provocative) Fuck the set of all cypherpunks who fluff Assadnge endlessly. Part the Second, deliberate and careful) Fuck the set of all cypherpunks who, like looking at the one-way direction of prime numbers, want all ExploitativeQuidProQuos/IdentityPoliticsImpermeableBoundaries to continue forever because they want victory for able bodied and for hoarders. Part the Third, deliberate but with a touch of scherzo suggesting erroneous grep -v and grep not piping across &&s correctly) Reward the set of all cypherpunks who in their verily verily souls, want the unpaid invoices of the lifegiving to flow back to the great-grandmothers, etc., while still understanding all humans are one, and an injustice to any single human is an injustice to all humans, so on, so forth. Part the Fourth, presto vivace, scherzo increasing ad infinitum) Can someone recommend which LaTeX will work with which prices for dedicated hardware RAM drives combined with annual and monthly commodity prices for centuries and World Banks and Galactic crop sections and old science fiction models as my eyes spin like economic cycles flowing around unchanging charts of households and firms? If a browser-based Jitsi Meet goes up the butt of a client-installed Zoom client even with zoombombing patched as the passports divide and recombine, exploding with combinations far beyon the Cambrian era of Pantera's Vulgar Display of Power out Phil Anselmo's psychopharmaceutical prescriber's other nyms making fun of the set of all possible heavy metal maniacs who need lorazepam like a threesome in the South China Sea as turmeric and ginger fall from the sky? Have fun, and happy rioting, self defense, and fucking up shit!

2 1

Localhost strikes again! - Kubernetes Vulnerability Puts Clusters at Risk of Takeover (CVE-2020-8558)
by coderman 29 Jul '20

29 Jul '20

one of my favorite Tor bugs relied on localhost :P [ https://archives.seul.org/or/announce/Sep-2007/msg00000.html ] --- https://unit42.paloaltonetworks.com/cve-2020-8558/ Kubernetes Vulnerability Puts Clusters at Risk of Takeover (CVE-2020-8558) Executive Summary A security issue assigned [CVE-2020-8558](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8558) was recently discovered in the kube-proxy, a networking component running on Kubernetes nodes. The issue exposed internal services of Kubernetes nodes, often run without authentication. On certain Kubernetes deployments, this could have exposed the api-server, allowing an unauthenticated attacker to gain complete control over the cluster. An attacker with this sort of access could steal information, deploy crypto miners or remove existing services altogether. The vulnerability exposed nodes’ localhost services – services meant to be accessible only from the node itself – to hosts on the local network and to pods running on the node. Localhost bound services expect that only trusted, local processes can interact with them, and thus often serve requests without authentication. If your nodes run localhost services without enforcing authentication, you are affected. The issue details were [made public](https://github.com/kubernetes/kubernetes/issues/90259) on April 18, 2020, and a [patch](https://github.com/kubernetes/kubernetes/pull/91569) released on June 1, 2020. We worked to assess additional impact to Kubernetes clusters and found that some Kubernetes installations don’t disable the api-server insecure-port, which is normally only accessible from within the master node. Exploiting CVE-2020-8558, attackers can gain access to the insecure-port and gain full control over the cluster. We alerted the Kubernetes security team of the potential impact of this vulnerability. In turn, the team rated the vulnerability’s impact as High in clusters where the api-server insecure-port is enabled, and otherwise Medium. Luckily, CVE-2020-8558’s impact is somewhat reduced on most hosted Kubernetes services like Azure Kubernetes Service (AKS), Amazon’s Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE). CVE-2020-8558 was patched in Kubernetes versions v1.18.4, v1.17.7, and v1.16.11 (released June 17, 2020). All users are encouraged to update. Prisma Cloud customers are protected from this vulnerability through the capabilities described in the Conclusion section. The kube-proxy kube-proxy is a network proxy running on each node in a Kubernetes cluster. Its job is to manage connectivity among pods and services. [Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/) expose a single clusterIP, but may consist of multiple backing pods to enable load balancing. A service may consist of three pods – each with its own IP address – but will expose only one clusterIP, for example, 10.0.0.1. Pods accessing that service will send packets to its clusterIP, 10.0.0.1, but must somehow be redirected to one of the pods behind the service abstraction. That’s where the kube-proxy comes in. It sets up routing tables on each node, so that requests targeting a service will be correctly routed to one of the pods backing that service. It’s commonly deployed as a static pod or as part of a DaemonSet. [GKE’s documentation](https://cloud.google.com/kubernetes-engine/docs/concepts/net… has further details, if you’re interested. There are networking solutions, such as [Cilium](https://cilium.io/), that could be configured to fully replace the kube-proxy. The Culprit Is route_localnet As part of its job, the kube-proxy configures several network parameters through [sysctl files](https://www.kernel.org/doc/Documentation/sysctl/README). One of those is net.ipv4.conf.all.route_localnet – the culprit behind this vulnerability. [Sysctl documentation](https://sysctl-explorer.net/net/ipv4/route_localnet/) states, “route_localnet: Do not consider loopback addresses as martian source or destination while routing. This enables the use of 127/8 for local routing purposes. default FALSE.” Let’s unpack that explanation. For IPv4, the loopback addresses consist of the 127.0.0.0/8 address block (127.0.0.1-127.255.255.255), while commonly only 127.0.0.1 is used and has the hostname “localhost” mapped to it. Those are addresses used by your machine to refer to itself. Packets targeting a local service will be sent to IP 127.0.0.1 through the loopback network interface, with their source IP set to 127.0.0.1 as well. Setting route_localnet instructs the kernel to not define 127.0.0.1/8 IP addresses as martian. What does “martian” mean in this context? Well, some packets arrive at a network interface and make claims about their source or destination IP that just don’t make sense. For example, a packet could arrive with a source IP of 255.255.255.255. That packet shouldn’t exist: 255.255.255.255 can’t identify a host, it’s a reserved address used to indicate broadcast. So what’s going on? Your kernel can’t know for sure and has no choice but to conclude the packet came from Mars and should be dropped. Martian packets often hint that someone malicious on the network is trying to attack you. In the example above, the attacker may want your service to respond to IP 255.255.255.255, causing routers to broadcast the response. A fishy destination IP can also cause a packet to be deemed martian, such as a packet arriving at an external network interface with a destination IP of 127.0.0.1. Again, that packet doesn’t make sense – 127.0.0.1 is used for internal communication through the loopback interface and shouldn’t arrive from a network-facing interface. For more details on martian packets, refer to [RFC 1812](https://tools.ietf.org/html/rfc1812#section-5.3.7). In some complicated routing scenarios, you might want the kernel to let certain martian packets pass through. That’s what route_localnet is used for. It instructs the kernel not to consider 127.0.0.0/8 as martian addresses (as it normally would, like in the case discussed in the previous paragraph). The kube-proxy enables route_localnet to support a bunch of routing magic that I won’t get into, but route_localnet is disabled by default for a reason. Unless proper mitigation is set up alongside it, attackers on the local network could exploit route_localnet to perform several attacks. The most impactful is reaching localhost bound services. Localhost-only Services Linux allows processes to listen only on a specific IP address so that they can bind themselves to the address of a network interface. Internal services often use that feature to listen only on 127.0.0.1. Normally, this ensures that only local processes can access the service, as only they can reach 127.0.0.1. This assumption is broken with route_localnet, since it allows external packets destined for 127.0.0.0/8. That’s highly concerning given internal services tend not to enforce authentication, expecting external packets will not reach them. Reaching Internal Services An attacker attempting to reach the victim’s internal services would need to construct a malicious packet where the destination IP address is set to 127.0.0.1 and the destination MAC address is set to the victim’s MAC address. Without a meaningful destination IP, the attacker’s packet only relies on layer 2 (MAC-based) routing to reach the victim and is thus limited to the local network. Therefore, even if a victim enabled route_localnet, only attackers on the local network could access the victim’s localhost services. When the victim machine receives the malicious packet, it will let it pass because of route_localnet. Since the packet has a destination IP of 127.0.0.1, it would be eligible to access localhost services. Table 1 shows what a malicious packet may look like. The attacker’s IP is 10.0.0.1 with MAC address XXX, and the target IP is 10.0.0.0.2 with MAC address YYY. The target is running a localhost-only service on port 1234. src mac XXX dst mac YYY src ip 10.0.0.1 dst ip 127.0.0.1 src port random dst port 1234 Figure 1. A packet exploiting route_localnet The attacker sends the packet with his IP address to ensure he receives the target’s responses. To summarize, route_localnet allows attackers on the local network to access a host’s internal services with packets like the one shown above. Back to the Kubernetes Vulnerability (CVE-2020-8558) Because of kube-proxy, every node in the cluster has route_localnet enabled. As a result, every host on a node’s local network could gain access to the node’s internal services. If your nodes run internal services without authentication, you are affected. Aside from neighboring hosts on a node’s local network, pods running on the node could also access its internal services. To be clear, a pod can only reach the internal services of the node hosting it. To carry out the attack, the pod must possess the CAP_NET_RAW capability. Unfortunately, Kubernetes grants this capability by default. When we examined this issue, we tried to identify localhost services that are natively deployed by Kubernetes. We found that by default, the Kubenetes API server serves unauthenticated requests on localhost through a port dubbed the insecure-port. The insecure-port exists to allow other control-plane components running on the master (such as etcd) to easily talk with the api-server. Role-based access control (RBAC) or any other authorization mechanisms are not enforced on that port. Kubernetes installations frequently run the api-server as a pod on the master node, meaning it is running alongside a kube-proxy that has enabled route_localnet. Alarmingly, this means that if your Kubernetes deployment didn’t disable the insecure-port, hosts on the master node’s local network could exploit CVE-2020-8558 to command the api-server and gain complete control over the cluster. Managed Kubernetes Managed Kubernetes platforms such as GKE, EKS and AKS are better protected against CVE-2020-8558. To begin with, the virtual networks of some cloud service providers (CSPs), such as [Microsoft Azure](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-netwo…, don’t support layer-2 semantics and MAC-based routing. You can easily see how this manifests – every AKS machine has the same MAC address: 12:34:56:78:9A:BC. This mitigates exploitation of CVE-2020-8558 from other hosts on a node’s local network, but malicious pods possessing CAP_NET_RAW should still be able to carry out the attack. Cloud-hosted Kubernetes offerings also tend to manage the Kubernetes control plane and api-server for you and run them on a separate network from the rest of the cluster. This protects the api-server, as it isn’t exposed to the rest of the cluster. Even if a CSP would run the api-server without disabling the insecure-port, attackers in the cluster wouldn’t be able to access it as they don’t run in the same local network. Still, if your CSP virtual network does support layer-2 routing, malicious hosts in your cluster’s network could access localhost services on the worker nodes. The Fix The [initial fix](https://github.com/kubernetes/kubernetes/pull/91569) actually resides in the kubelet and adds mitigations around route_localnet: routing rules that cause nodes to drop external packets destined for 127.0.0.1. At the time of writing this post, route_localnet is still enabled by the kube-proxy. There are [ongoing discussions](https://github.com/kubernetes/kubernetes/issues/90259#issuecom… about [disabling it](https://github.com/kubernetes/kubernetes/issues/90259). Even with those mitigations applied, there’s still a special case where a local network attacker could send packets to nodes’ internal UDP services. However, the attack only works if the victim node disables [reverse path filtering (](https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html)which normally isn’t case), and in this circumstance the attacker won’t be able to get the response. A [patch](https://github.com/kubernetes/kubernetes/pull/91666) is being developed, but it may be dropped as the attack depends on an insecure setting (rp_filter=0). Am I Affected? If all of the below are true, your cluster is vulnerable to CVE-2020-8558: - Your cluster is running a vulnerable version (earlier than v1.18.4, v1.17.7, and v1.16.11). - Note that while the issue originated from the kube-proxy, the patch is in the kubelet. - Your nodes have the kube-proxy running on them. - Your nodes (or hostnetwork pods) run localhost-only services which don’t require any further authentication. Additionally, if the following is also true, your cluster may be vulnerable to a complete takeover through the api-server insecure-port: - Your cluster doesn’t disable the api-server insecure-port via –insecure-port=0 - The api-server runs on a node alongside a kube-proxy, for example, in deployments where the api-server is a pod itself. A node could be attacked either by a malicious host on the local network or by a malicious pod with CAP_NET_RAW running on the node. Conclusion CVE-2020-8558 can have some serious consequences. You should patch your clusters as soon as possible. CVE-2020-8558 also serves as a reminder that security best practices do work and significantly reduce attack surface. You should disable the api-server insecure-port, and if your pods don’t require CAP_NET_RAW, there’s no reason they should have that capability. While not related to this specific issue, we recommend implementing other security recommendations such as RBAC or running containers as a non-root user. Palo Alto Networks [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) customers are protected from this vulnerability. Compliance rules ensure your clusters are configured securely, blocking or alerting on: - The api-server insecure port - Pods running with CAP_NEW_RAW

1 0

There’s a Hole in the Boot
by coderman 29 Jul '20

29 Jul '20

https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ “BootHole” vulnerability in the GRUB2 bootloader opens up Windows and Linux devices using Secure Boot to attack. All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders. [Download the PDF >](https://eclypsium.com/wp-content/uploads/2020/07/Theres-a-Hole-in-the-Boot.pdf) Introduction Eclypsium researchers have discovered a vulnerability — dubbed “BootHole” — in the GRUB2 bootloader utilized by most Linux systems that can be used to gain arbitrary code execution during the boot process, even when Secure Boot is enabled. Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device. The vulnerability affects systems using Secure Boot, even if they are not using GRUB2. Almost all signed versions of GRUB2 are vulnerable, meaning virtually every Linux distribution is affected. In addition, GRUB2 supports other operating systems, kernels and hypervisors such as Xen. The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. Thus the majority of laptops, desktops, servers and workstations are affected, as well as network appliances and other special purpose equipment used in industrial, healthcare, financial and other industries. This vulnerability makes these devices susceptible to attackers such as the [threat actors recently discovered](https://twitter.com/ESETresearch/status/1275770256389222400) using malicious UEFI bootloaders. Eclypsium has coordinated the responsible disclosure of this vulnerability with a variety of industry entities, including OS vendors, computer manufacturers, and CERTs. Mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack. This will likely be a long process and take considerable time for organizations to complete patching. Table of Contents - [Background: Secure Boot, GRUB2, and CAs](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#background) - [Threats to the Boot Process](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#threat… - [UEFI Secure Boot](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#uefi) - [Chains of Trust and GRUB2](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#chains) - [Challenges of Secure Boot](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#challenge… - [Breaking Secure Boot Through GRUB2](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#breaking) - [Vulnerability Analysis](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#vulne… - [Additional Vulnerabilities](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot… - [Impact](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#impacts) - [Mitigation](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#mit… - [Recommendations](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot… - [Conclusions](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#co… Background: Secure Boot, GRUB2, and CAs Secure Boot can be a fairly deep and technical topic. Our goal here is to give a high-level introduction to the key concepts relevant to this research without going into all the granular details. We have included a variety of external links to provide additional information for those interested. Alternatively, you can go straight to the [description of the vulnerability](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#… itself. Threats to the Boot Process The boot process is one of the most fundamentally important aspects of security for any device. It relies on a variety of firmware that controls how a device’s various components and peripherals are initialized and ultimately coordinates the loading of the operating system itself. In general, the earlier code is loaded, the more privileged it is. If this process is compromised, attackers can control how the operating system is loaded and subvert all higher-layer security controls. Recent research has identified ransomware in the wild using [malicious EFI bootloaders](https://twitter.com/ESETresearch/status/1275770256389222400) as a way to take control of machines at the time of boot. Previously threat actors used malware tampering with legacy OS bootloaders including [APT41 Rockboot](https://attack.mitre.org/software/S0112/), [LockBit](https://news.sophos.com/en-us/2020/04/24/lockbit-ransomware-borrow…, [FIN1 Nemesis](https://arstechnica.com/information-technology/2015/12/nemesis-mal…, [MBR-ONI](https://www.cybereason.com/blog/night-of-the-devil-ransomware-or-w…, [Petya/NotPetya](https://us-cert.cisa.gov/ncas/alerts/TA17-181A), and [Rovnix](https://malpedia.caad.fkie.fraunhofer.de/details/win.rovnix). Additional information on threats to the modern PC boot process is available in the “[Bootkits and UEFI Secure Boot](https://github.com/abazhaniuk/firmware-security-training/blob/master/… section of the System Firmware training. UEFI Secure Boot UEFI Secure Boot was originally developed by the UEFI Forum as a way to protect the boot process from these types of attacks. There are other implementations of secure boot designed for different environments, but UEFI Secure Boot is the standard for PCs and servers. The goal is to prevent malicious code from being introduced into the boot process by cryptographically checking each piece of firmware and software before it is run. Any code not recognized as valid is not executed in the boot process. Secure Boot uses cryptographic signatures to verify the integrity of each piece of code as it is needed during the boot process. There are two critical databases involved in this process: the Allow DB (db) of approved components and the Disallow DB (dbx) of vulnerable or malicious components, including firmware, drivers, and bootloaders. Access to modify these databases is protected by a Key Exchange Key (KEK), which in turn is verified by a Platform Key (PK). Although the PK is used as a root of trust for updates to the platform, it’s not expressly part of the boot process (but is shown below for reference). It is dbx, db, and KEK that are used to verify the signatures for loaded executables at boot time. Additional details on the Secure Boot process can be found in this [PDF](http://www.c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf). Chains of Trust and GRUB2 Next, OEMs must manage a list of who is permitted to sign code trusted by the Secure Boot Database. Instead of having every OEM manage certificates from every possible firmware, driver, or OS provider, Secure Boot allows for the use of a centralized Certificate Authority (CA). Microsoft’s 3rd Party UEFI CA provides the industry standard signing service for Secure Boot. In short, third parties can submit their code to Microsoft, and Microsoft will validate and sign the code with the Microsoft CA. This establishes a chain of trust that only requires OEMs to enroll the Microsoft 3rd Party UEFI CA to their platforms to enable them to boot third-party installation media and operating systems by default when Secure Boot is enabled. This includes the ability to sign bootloaders from non-Microsoft operating systems such as Linux. In almost every modern Linux distribution, GRUB (the Grand Unified Bootloader) is the bootloader that loads and transfers control to the operating system. In this document, all references to GRUB are intended to refer to GRUB2, which was a complete rewrite from the previous version commonly referred to as “GRUB Legacy.” Starting in 2009, all widely used Linux distributions have transitioned to using GRUB2. GRUB Legacy has been deprecated and is generally only found in older releases. [Due to legal issues arising from license incompatibilities](https://techcommunity.microsoft.com/t5/hardware-dev-cent…, open-source projects and other third parties build a small application called a “shim,” which contains the vendor’s certificate and code that verifies and runs the bootloader (GRUB2). The vendor’s shim is verified using the Microsoft 3rd Party UEFI CA and then the shim loads and verifies the GRUB2 bootloader using the vendor certificate embedded inside itself. Additional detail on the role of the Microsoft UEFI CA in the boot process is available [here](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop…. Challenges of Secure Boot As with any technical process, Secure Boot is not without its potential problems. The process involves many pieces of code, and a vulnerability in any one of them presents a single point of failure that could allow an attacker to bypass Secure Boot. Additionally, although UEFI Secure Boot attempts to provide certain integrity guarantees to the boot process, other misconfigurations of the hardware or missing protection features can undermine boot security. One such example is a [DMA attack](https://eclypsium.com/2020/01/30/direct-memory-access-attacks/) using tools such as [PCIe Microblaze](https://github.com/Cr4sh/s6_pcie_microblaze). Additionally, as we will show in this blog post, a vulnerability in the boot process that enables arbitrary code execution can allow attackers to control the boot process and operating system, even when secure boot signatures are verified. Attackers can also use a vulnerable bootloader against the system. For example, if a valid bootloader was found to have a vulnerability, a piece of malware could replace the device’s existing bootloader with the vulnerable version. The bootloader would be allowed by Secure Boot and give the malware complete control over the system and OS. Mitigating this requires very active management of the dbx database used to identify malicious or vulnerable code. Additionally, updates and fixes to the Secure Boot process can be particularly complex and run the risk of inadvertently [breaking machines](https://www.securityweek.com/microsoft-pulls-uefi-related-windows…. The boot process naturally involves a variety of players and components including device OEMs, operating system vendors, and administrators. Given the fundamental nature of the boot process, any sort of problems run a high risk of rendering a device unusable. As a result, updates to Secure Boot are typically slow and require extensive industry testing. Breaking Secure Boot Through GRUB2 In the course of Eclypsium’s analysis, we have identified a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg). Of note: The GRUB2 config file is a text file and typically is not signed like other files and executables. This vulnerability enables arbitrary code execution within GRUB2 and thus control over the booting of the operating system. As a result, an attacker could modify the contents of the GRUB2 configuration file to ensure that attack code is run before the operating system is loaded. In this way, attackers gain persistence on the device. Such an attack would require an attacker to have elevated privileges. However, it would provide the attacker with a powerful additional escalation of privilege and persistence on the device, even with Secure Boot enabled and properly performing signature verification on all loaded executables. One of the explicit design goals of Secure Boot is to prevent unauthorized code, even running with administrator privileges, from gaining additional privileges and pre-OS persistence by disabling Secure Boot or otherwise modifying the boot chain. With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable. As such, this will require the release of new installers and bootloaders for all versions of Linux. Vendors will need to release new versions of their bootloader shims to be signed by the Microsoft 3rd Party UEFI CA. It is important to note that until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system. This means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time. In addition to vendors using shims signed by the Microsoft 3rd Party UEFI CA, some OEMs that control both the hardware and the software stack in their devices use their own key that is provisioned into the hardware at the factory to sign GRUB2 directly. They will need to provide updates and revocation of previous vulnerable versions of GRUB2 for these systems as well. This vulnerability was assigned CVE-2020-10713 “GRUB2: crafted grub.cfg file can lead to arbitrary code execution during boot process” with a CVSS rating of 8.2 (High) / CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. Follow these links to go directly to the [Impact](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#impacts) and [Mitigations](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#mi… sections. Vulnerability Analysis The vulnerability is a buffer overflow that occurs in GRUB2 when parsing the grub.cfg file. This configuration file is an external file commonly located in the EFI System Partition and can therefore be modified by an attacker with administrator privileges without altering the integrity of the signed vendor shim and GRUB2 bootloader executables. The buffer overflow allows the attacker to gain arbitrary code execution within the UEFI execution environment, which could be used to run malware, alter the boot process, directly patch the OS kernel, or execute any number of other malicious actions. To dig a little deeper into the vulnerability itself, we’ll take a closer look at how the code works internally. In order to process commands from the external configuration file, GRUB2 uses flex and bison to generate a parsing engine for a domain-specific language (DSL) from language description files and helper functions. This is generally considered to be a better approach than manually writing a custom parser for each DSL. However, GRUB2, flex, and bison are all complex software packages with their own design assumptions that can be easy to overlook. And those mismatched design assumptions can result in vulnerable code. The parser engine generated by flex includes this define as part of the token processing code: #define YY_DO_BEFORE_ACTION \ yyg->yytext_ptr = yy_bp; \ yyleng = (int) (yy_cp - yy_bp); \ yyg->yy_hold_char = *yy_cp; \ *yy_cp = '\0'; \ if ( yyleng >= YYLMAX ) \ YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \ yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \ yyg->yy_c_buf_p = yy_cp; In this macro, the generated code detects that it has encountered a token that is too large to fit into flex’s internal parse buffer and calls YY_FATAL_ERROR(), which is a helper function provided by the software that is using the flex-generated parser. However, the YY_FATAL_ERROR() implementation provided in the GRUB2 software package is: #define YY_FATAL_ERROR(msg) \ do { \ grub_printf (_("fatal error: %s\n"), _(msg)); \ } while (0) Rather than halting execution or exiting, it just prints an error to the console and returns to the calling function. Unfortunately, the flex code has been written with the expectation that any calls to YY_FATAL_ERROR() will never return. This results in yy_flex_strncpy() being called and copying the source string from the configuration file into a buffer that is too small to contain it. Beyond just this specific path, a number of additional places throughout the flex-generated code also expect that any calls to YY_FATAL_ERROR() never return and perform unsafe operations when that expectation is broken. Mismatched assumptions between producers and consumers of an API are a very common source of vulnerabilities. Ultimately, by providing a configuration file with input tokens that are too long to be handled by the parser, this buffer overflow overwrites critical structures in the heap. These overwritten fields include internal parser structure elements, which can be used as an arbitrary write-what-where primitive to gain arbitrary code execution and hijack the boot process. Of further note, the UEFI execution environment does not have Address Space Layout Randomization (ASLR) or Data Execution Prevention (DEP/NX) or other exploit mitigation technologies typically found in modern operating systems, so creating exploits for this kind of vulnerability is significantly easier. The heap is fully executable without the need to build ROP chains. Finally, rather than being architecture-specific, this vulnerability is in a common code path and was also confirmed using a signed ARM64 version of GRUB2. Additional Vulnerabilities There have been a couple of examples of previous vulnerabilities found in GRUB2 that result in arbitrary code execution, but with a much smaller scope. In April 2019, a vulnerability in how GRUB2 was used by the Kaspersky Rescue Disk was [publicly disclosed](https://habr.com/en/post/446238/). In February 2020, more than six months after a fixed version had been released, Microsoft pushed an update to revoke the vulnerable bootloader across all Windows systems by updating the UEFI revocation list (dbx) to block the known-vulnerable Kaspersky bootloader. Unfortunately, this resulted in systems from multiple vendors encountering unexpected errors, including bricked devices, and the [update was removed from the update servers](https://www.windowslatest.com/2020/02/15/windows-10-kb4524244-issu…. Additionally, in May 2020, Dmytro Oleksiuk [disclosed](https://twitter.com/d_olex/status/1264238411679887360) that certain HPE ProLiant servers contained a version of GRUB2 signed by a HP CA that allows the use of the “insmod” command to load unsigned code. This issue was assigned CVE-2020-7205 and is also embargoed until July 29th. In response to our initial vulnerability report, additional scrutiny was applied to the GRUB2 code and a number of additional vulnerabilities were discovered by the Canonical security team: - CVE-2020-14308 GRUB2: grub_malloc does not validate allocation size allowing for arithmetic overflow and subsequent heap-based buffer overflow - 6.4 (Medium) / CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H - CVE-2020-14309 GRUB2: Integer overflow in grub_squash_read_symlink may lead to heap based overflow - 5.7 (Medium) / CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H - CVE-2020-14310 GRUB2: Integer overflow read_section_from_string may lead to heap based overflow - 5.7 (Medium) / CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H - CVE-2020-14311 GRUB2: Integer overflow in grub_ext2_read_link leads to heap based buffer overflow, - 5.7 (Medium) / CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H - CVE-2020-15705 GRUB2: avoid loading unsigned kernels when grub is booted directly under secure boot without shim - 6.4 (Medium) /CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H - CVE-2020-15706 GRUB2 script: Avoid a use-after-free when redefining a function during execution - 6.4 (Medium) /CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H - CVE-2020-15707 GRUB2: Integer overflow in initrd size handling. - 5.7 (Medium) /CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H Given the difficulty of this kind of ecosystem-wide update/revocation, there is a strong desire to avoid having to do it again six months later. To that end, a large effort — spanning multiple security teams at Oracle, Red Hat, Canonical, VMware, and Debian — using static analysis tools and manual review helped identify and fix dozens of further vulnerabilities and dangerous operations throughout the codebase that do not yet have individual CVEs assigned. Impact Due to a weakness in the way GRUB2 parses its configuration file, an attacker can execute arbitrary code that bypasses signature verification. The Boot Hole vulnerability discovered by Eclypsium can be used to install persistent and stealthy bootkits or malicious bootloaders that operate even when Secure Boot is enabled and functioning correctly. This can ensure attacker code runs before the operating system and can allow the attacker to control how the operating system is loaded, directly patch the operating system, or even direct the bootloader to alternate OS images. It gives the attacker virtually unlimited control over the victim device. Malicious bootloaders have recently been [observed in the wild](https://twitter.com/ESETresearch/status/1275770256389222400), and this vulnerability would make devices susceptible to these types of threats. All signed versions of GRUB2 that read commands from an external grub.cfg file are vulnerable, affecting every Linux distribution. To date, more than 80 shims are known to be affected. In addition to Linux systems, any system that uses Secure Boot with the standard Microsoft UEFI CA is vulnerable to this issue. As a result, we believe that the majority of modern systems in use today, including servers and workstations, laptops and desktops, and a large number of Linux-based OT and IoT systems, are potentially affected by these vulnerabilities. Additionally, any hardware root of trust mechanisms that rely on UEFI Secure Boot could be bypassed as well. Mitigation Full mitigation of this issue will require coordinated efforts from a variety of entities: affected open-source projects, Microsoft, and the owners of affected systems, among others. This will include: - Updates to GRUB2 to address the vulnerability. - Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims. - New shims will need to be signed by the Microsoft 3rd Party UEFI CA. - Administrators of affected devices will need to update installed versions of operating systems in the field as well as installer images, including disaster recovery media. - Eventually the [UEFI revocation list (dbx)](https://uefi.org/revocationlistfile) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot. On the Coordinated Release Date (CRD) of July 29, we expect to see advisories and/or updates from the following affected parties: - Microsoft - UEFI Security Response Team (USRT) - Oracle - Red Hat (Fedora and RHEL) - Canonical (Ubuntu) - SuSE (SLES and openSUSE) - Debian - Citrix - VMware - Various OEMs - Software vendors, including security software, are also impacted by this vulnerability and will be updating their bootloaders. - … more to be added once we have a full list … However, full deployment of this revocation process will likely be very slow. UEFI-related updates have had a [history of making devices unusable](https://www.securityweek.com/microsoft-pulls-uefi-related-windows…, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim are updated, then the operating system will not load. As a result, updates to the revocation list will take place over time to prevent breaking systems that have yet to be updated. There are also edge cases where updating the dbx can be difficult, such as with dual-boot or deprovisioned machines. When any OS is installed or launched, the bootloader and OS need to be updated before the revocation is applied to the system. Further complicating matters, enterprise disaster recovery processes can run into issues where approved recovery media no longer boots on a system if dbx updates have been applied. In addition when a device swap is needed due to failing hardware, new systems of the same model may have already had dbx updates applied and will fail when attempting to boot previously-installed operating systems. Before dbx updates are pushed out to enterprise fleet systems, recovery and installation media must be updated and verified as well. Microsoft will be releasing a set of signed dbx updates, which can be applied to systems to block shims that can be used to load the vulnerable versions of GRUB2. Due to the risk of bricking systems or otherwise breaking operational or recovery workflows, these dbx updates will initially be made available for interested parties to manually apply to their systems rather than pushing the revocation entries and applying them automatically. This will allow IT professionals, enthusiasts, and others the opportunity to test the revocation updates on their individual systems and identify any issues before making the revocations mandatory. Organizations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems. Organizations should also test recovery capabilities as updates become available, including the “reset to factory defaults” functionality in the UEFI setup. This will ensure that they can recover devices if a device is negatively impacted by an update. Finally, organizations should be monitoring their systems for threats and ransomware that use vulnerable bootloaders to infect or damage systems. Recommendations - Right away, start monitoring the contents of the bootloader partition (EFI system partition). This will buy time for the rest of the process and help identify affected systems in your environment. For those who have deployed the Eclypsium solution, you can see this monitoring under the “MBR/Bootloader” component of a device. - Continue to install OS updates as usual across desktops, laptops, servers, and appliances. Attackers can leverage privilege escalation flaws in the OS and applications to take advantage of this vulnerability so preventing them from gaining administrative level access to your systems is critical. Systems are still vulnerable after this, but it is a necessary first step. Once the revocation update is installed later, the old bootloader should stop working. This includes rescue disks, installers, enterprise gold images, virtual machines, or other bootable media. - Test the revocation list update. Be sure to specifically test the same firmware versions and models that are used in the field. It may help to update to the latest firmware first in order to reduce the number of test cases. - To close this vulnerability, you need to deploy the revocation update. Make sure that all bootable media has received OS updates first, roll it out slowly to only a small number of devices at a time, and incorporate lessons learned from testing as part of this process. - Engage with your third-party vendors to validate they are aware of, and are addressing, this issue. They should provide you a response as to its applicability to the services/solutions they provide you as well as their plans for remediation of this high rated vulnerability. Conclusions While Secure Boot is easily taken for granted by most users, it is the foundation of security within most devices. Once compromised, attackers can gain virtually complete control over the device, its operating system, and its applications and data. And as this research shows, when problems are found in the boot process, they can have far-reaching effects across many types of devices. We will update this blog post as more information becomes available, and we encourage users and administrators to closely monitor alerts and notifications from their hardware vendors, the [Microsoft MSRC](https://www.microsoft.com/en-us/msrc), and any relevant open-source projects. Please join us for a webinar “[Managing the Hole in Secure Boot](https://www.brighttalk.com/webcast/17865/430345?utm_source=Eclypsium&… on August 5th. References: - Microsoft - Security advisory - https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011 - UEFI Forum - Updated Revocation List - https://uefi.org/revocationlistfile - Debian - Security advisory - https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot - Canonical: - Security advisory - https://ubuntu.com/security/notices/USN-4432-1 - KnowledgeBase article - https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass - Red Hat - Customer documentation - https://access.redhat.com/security/vulnerabilities/grub2bootloader - SUSE - Security advisory: - https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/ - Knowledge Base article: - https://www.suse.com/support/kb/doc/?id=000019673 - HP - Security advisory - [HPSBHF03678 rev. 1 – GRUB2 Bootloader Arbitrary Code Execution](https://support.hp.com/us-en/document/c06707446) - HPE - Security advisory - https://techhub.hpe.com/eginfolib/securityalerts/Boot_Hole/boot_hole.html - VMware - Security advisory - https://kb.vmware.com/s/article/80181 - Upstream Grub2 project - [GRUB2 Git Repository](http://git.savannah.gnu.org/gitweb/?p=grub.git&view=view+git+re… - [GRUB Developer Mailing List](https://lists.gnu.org/mailman/listinfo/grub-devel/)

1 0