Received: by 10.223.164.202 with SMTP id h10csp256151wrb; Fri, 10 Nov 2017 05:57:33 -0800 (PST) X-Google-Smtp-Source: AGs4zMZK+e0isXQpgFHtDpoN+sioPueGtGTx3HRzBww25WXU9uG53fahY4pf1comcpUJWlPIk8mi X-Received: by 10.84.217.154 with SMTP id p26mr466398pli.132.1510322253269; Fri, 10 Nov 2017 05:57:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510322253; cv=none; d=google.com; s=arc-20160816; b=Y+smBpRttXALKtQHpsDpGhKlQ+dhdclvmk3C+sQaRZ7n8TuABANpg519HKi6nYWeSf rPayBZ/EOx29GRuKHaAeUps8Lwoh1dGQtzenfZsoIHY3bpLPkFqORJxBinIOXlYeCaV2 4qbnc9qYkRHY9l5VTYAol5rZZkVB4RTayosxISg8yWmUS9mm7gwFhi5mysvMa9392A/E XO0rVNVU9EXt/YlSv0FY0N1y10Z+HqUYKXIJcuNSzhzT86Oc6SERi3epGqoyzJGI3I6X jQ9tM6Dh5jRx4XhbWriVSok1/hfbqRjtdjnNk1lSVhOpkC/PD5uEaipS79tCUr54vkpC eI/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=o0TXcErv7D07fPEMzw+Ao3KU8w/EIo1IK49sSHZvY2A=; b=I+Lv5zsOJ1BQFgAqtJgZcgc6+l5jiuz0wwi8Jt4kT4E8b7qbswvhEGfqkek7zW5hIF rhJhE9HQBnsgHez7lG/1ByiMYkLD7aC7CEziH0+ctlwoqM5HheW+QzqZUgjI1yG3WSQG PTIsU/dIpRcYCEoRNUy1xprEgauAws3ibSltHSH9WnjIDRpScE7z3XoKI4JBkZQnqAfs yYcjU7IWV67iTT0L2y3y7OUDSQZdzPr0wW+/3OOzR7VK8oC6Y6xZRu9AdjALYh24R9aC DYbSoBdWsXNXO05BLyTm9Gk2szAfBNmWmjIuBgursgIwgv41bZeXSarirI848jOuqaz9 G/UQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZoWYnNQ2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si4031950pld.213.2017.11.10.05.57.21; Fri, 10 Nov 2017 05:57:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZoWYnNQ2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753241AbdKJN4q (ORCPT + 83 others); Fri, 10 Nov 2017 08:56:46 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:47967 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753188AbdKJN4n (ORCPT ); Fri, 10 Nov 2017 08:56:43 -0500 Received: by mail-pf0-f193.google.com with SMTP id z80so6694334pff.4; Fri, 10 Nov 2017 05:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=o0TXcErv7D07fPEMzw+Ao3KU8w/EIo1IK49sSHZvY2A=; b=ZoWYnNQ2jJuSMQhhEVVk1l02VjwZ7VJ0TDFSGIkl1uB/ZzqTDV9+RCNUm30nWmfPLb WosKz1jl9XUCpkfwws1/MXFCcLffAOU8noURMkXsD7FHUCvNQeGpeemfvhjwLqw2bx9Q Rp/hO/rHDQ8ztyYbvHruDRzYiqsz+ZTXr2vPEJltzkEI427FysN5ZHZ9Jy3MvTkTvUmT bcQX69C6A+2KpCeSGKVC0RDRxNrBpSk2MZwGnH62i3JWbIvY52LdrsFTp+/wrMbNoZlh VL16fgjgfHm5Tg1T1Pthqw/6mIPuOyLOd5V0kJYrs6yCcESwaJQ8ijVzAXvij849Vuoz p8Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=o0TXcErv7D07fPEMzw+Ao3KU8w/EIo1IK49sSHZvY2A=; b=IuD8jXXiqQTwxE9LktK0OT49/8eEmndWX8QA6Pwo/pLHa6lwMND/SbT1iJHL9a6P1Q /a3FzGVlNI5ZwE0zY6ItC3WCyABbzxcMfjSLQvj2G3Iz/GzWg/DQuvXGrEABqz+oEWmY KqdeLQIkvft6Cm7NDeZ+7iz3PXbrNLecyLAnaLNZJ5xqBjqLDbIvJhdC2x7RZiWUj1AF RqVDySkkCMh+v2vE53uu79PebRDadx0UsaXHXSMqlTtyqRjrxhD4S8OtliReW5hVTPFJ KBFN7XNR9q3Wvh5gXxpVzCPYthuk4w24+4xYH9fjiyOa9QZxcS8fZ/mISMr0JGFVf94L AAkA== X-Gm-Message-State: AJaThX5w5RLfQj6vrevJXldN8G88O6GkjZwVuDMufn+gPJahQ2mK/ny5 GZZx9K5VM4TAtNBDd42FWEE= X-Received: by 10.98.144.129 with SMTP id q1mr494371pfk.38.1510322202542; Fri, 10 Nov 2017 05:56:42 -0800 (PST) Received: from klaptop ([49.207.61.12]) by smtp.gmail.com with ESMTPSA id i187sm18675159pfc.96.2017.11.10.05.56.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 Nov 2017 05:56:41 -0800 (PST) Message-ID: <1510322194.19812.3.camel@gmail.com> Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl From: kaiwan.billimoria@gmail.com To: "Tobin C. Harding" , kernel-hardening@lists.openwall.com Cc: "Jason A. Donenfeld" , Theodore Ts'o , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , linux-kernel@vger.kernel.org, Network Development , David Miller Date: Fri, 10 Nov 2017 19:26:34 +0530 In-Reply-To: <1510050731-32446-1-git-send-email-me@tobin.cc> References: <1510050731-32446-1-git-send-email-me@tobin.cc> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-11-07 at 21:32 +1100, Tobin C. Harding wrote: > Currently we are leaking addresses from the kernel to user space. > This > script is an attempt to find some of those leakages. Script parses > `dmesg` output and /proc and /sys files for hex strings that look > like > kernel addresses. > > Only works for 64 bit kernels, the reason being that kernel addresses > on 64 bit kernels have 'ffff' as the leading bit pattern making > greping > possible. On 32 kernels we don't have this luxury. Tobin C. Harding wrote: >Only works for 64 bit kernels, the reason being that kernel addresses >on 64 bit kernels have 'ffff' as the leading bit pattern making greping >possible. On 32 kernels we don't have this luxury. [RFC] leaking_addresses.pl - enhance it to work for 32-bit kernels as well (Firstly, apologies if I've got the protocol horribly wrong- should this be a new thread altogether?) Ok so, I was interested in figuring - why not have this useful script work for 32-bit kernel virtual addresses as well (and those systems by extension). The approach am considering, pl correct me if I'm way off: on 32-bit, the kernel macro PAGE_OFFSET will give us the user-kernel split; (alternatively, could also script up CONFIG_VMSPLIT_[n]G and figure the split from there.) For the time being, lets say we go with the "use PAGE_OFFSET" approach and PAGE_OFFSET = 0xc0000000 , whch implies we have a 3:1 GB user:kernel split. So any virtual addresses >= PAGE_OFFSET are kernel virtual addresses (i know, untrue on some ARM-32 systems!). As a very early and *far-from-perfect* start, I've enhanced Tobin's Perl script to take into account 32-bit address space by passing the parameter '--bit-size='. The patch below does Not take into account (yet) stuff like: - exactly which files & dirs should be skipped on 32-bit (will it be identical to 64-bit?; unsure..) - it currently hard-codes a global 'PAGE_OFFSET_32BIT=0xc0000000' , just so I can test quickly; must figure whether to query it or pass it; Suggestions? - the 'false positives'; again, what differs for 32-bit? (BTW, shouldn't the dmesg 'root=UUID=<...>' line be a false positive & skipped?). Also, I must point out that I'm a complete newbie to Perl :-) so, pl excuse my highly inadequate perl-foo; I rely on you perl gurus out there to fix and optimize :) Yes, I've **Very Minimally** tested the patch in it's current form on: a) a regular (Fedora 26) x86_64 desktop, b) a (Debian 7) 32-bit kernel (VM) with PAGE_OFFSET=3 Gb and it seems all right, considering... Some sample output from test (b), if interested: ===== dmesg: [ 0.000000] found SMP MP-table at [c00f1280] f1280 dmesg: [ 0.000000] Base memory trampoline at [c009b000] 9b000 size 16384 dmesg: [ 0.000000] ACPI: Local APIC address 0xfee00000 dmesg: [ 0.000000] free_area_init_node: node 0, pgdat c1418bc0, node_mem_map dfbfa200 dmesg: [ 0.000000] ACPI: Local APIC address 0xfee00000 dmesg: [ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) dmesg: [ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 dmesg: [ 0.000000] PERCPU: Embedded 14 pages/cpu @dfbe8000 s33344 r0 d24000 u57344 dmesg: [ 0.000000] fixmap : 0xffd36000 - 0xfffff000 (2852 kB) dmesg: [ 0.000000] pkmap : 0xffa00000 - 0xffc00000 (2048 kB) dmesg: [ 0.000000] vmalloc : 0xe07fb000 - 0xff9fe000 ( 498 MB) dmesg: [ 0.000000] lowmem : 0xc0000000 - 0xdfffb000 ( 511 MB) dmesg: [ 0.000000] .init : 0xc1421000 - 0xc148c000 ( 428 kB) [...] /proc/kallsyms: c10010e8 T _stext /proc/kallsyms: c1002000 T hypercall_page /proc/kallsyms: c1003000 t arch_local_save_flags /proc/kallsyms: c1003007 t arch_local_irq_enable /proc/kallsyms: c100300e T do_one_initcall << ... plenty more kallsyms of course (92.5% of the output to be precise!) ... >> /proc/modules: loop 17803 0 - Live 0xe097c000 /proc/modules: crc32c_intel 12659 0 - Live 0xe096e000 /proc/modules: snd_pcm 53461 0 - Live 0xe09f5000 /proc/modules: snd_page_alloc 12867 1 snd_pcm, Live 0xe0957000 /proc/modules: snd_timer 22401 1 snd_pcm, Live 0xe093c000 [...] /proc/modules: usb_common 12338 1 usbcore, Live 0xe0860000 /proc/timer_list: .base: dfbeb8b0 /proc/timer_list: #0: , tick_sched_timer, S:01, hrtimer_start_range_ns, swapper/0/0 [...] /proc/iomem: f8000000-fbffffff : 0000:00:02.0 /proc/iomem: fc000000-fcffffff : 0000:00:02.0 /proc/iomem: fd000000-fd03ffff : 0000:00:03.0 [...] /proc/11422/syscall: 7 0xffffffff 0xbf814618 0xa 0xa 0x0 0x1 0xbf8145b8 0xb7780428 /proc/11422/stack: [] kmap_atomic_prot+0x2f/0xe0 /proc/11422/stack: [] security_task_wait+0xc/0xd [...] /proc/bus/input/devices: B: KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe /proc/1/net/ipv6_route: 00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0000000f 00200200 lo [...] /proc/2/net/unix: dce872c0: 00000005 00000000 00000000 0002 01 4978 /dev/log /proc/2/net/unix: dce87a40: 00000002 00000000 00010000 0001 01 5006 /var/run/acpid.socket /proc/2/net/unix: dce87540: 00000002 00000000 00010000 0005 01 3246 /run/udev/control [...] ===== etc etc. Finally, unsure if am working against the latest ver of your script Tobin, apologies if not. Signed-off-by: Kaiwan N Billimoria --- diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl index 2977371b2956..b6280dca8c46 100755 --- a/scripts/leaking_addresses.pl +++ b/scripts/leaking_addresses.pl @@ -45,6 +45,7 @@ my $P = $0; my $V = '0.01'; # Directories to scan. +#my @DIRS = ('/home/kai/0tmp/addr32_pl'); my @DIRS = ('/proc', '/sys'); # Command line options. @@ -52,6 +53,7 @@ my $help = 0; my $debug = 0; my @dont_walk = (); my @dont_parse = (); +my $bit_size = 64; # Do not parse these files (absolute path). my @skip_parse_files_abs = ('/proc/kmsg', @@ -86,6 +88,8 @@ my @skip_walk_dirs_any = ('self', 'stdin', 'stdout'); +my $PAGE_OFFSET_32BIT = 0xc0000000; + sub help { my ($exitcode) = @_; @@ -96,10 +100,12 @@ Version: $V Options: + --bit-size= 32|[64] Checks for 64-bit kernel addresses by default; + change to check for 32-bit kernel addresses by passing 32 here --dont-walk= Don't walk tree starting at . --dont-parse= Don't parse . - -d, --debug Display debugging output. - -h, --help, --version Display this help and exit. + -d, --debug Display debugging output. + -h, --help, --version Display this help and exit. If an absolute path is passed to --dont_XXX then this path is skipped. If a single filename is passed then this file/directory will be skipped when @@ -117,8 +123,9 @@ EOM } GetOptions( - 'dont-walk=s' => \@dont_walk, - 'dont-parse=s' => \@dont_parse, + 'dont-walk=s' => \@dont_walk, + 'dont-parse=s' => \@dont_parse, + 'bit-size=i' => \$bit_size, 'd|debug' => \$debug, 'h|help' => \$help, 'version' => \$help @@ -126,6 +133,10 @@ GetOptions( help(0) if ($help); +if ($bit_size != 64 && $bit_size != 32) { + help(1); +} + push_to_global(); parse_dmesg(); @@ -168,6 +179,7 @@ sub push_to_global push_in_abs_any(\@dont_parse, \@skip_parse_files_abs, \@skip_parse_files_any); } +# NOT updated for 32-bit kernel addresses yet sub is_false_positive { my ($match) = @_; @@ -183,6 +195,7 @@ sub is_false_positive return 1; } +# TODO - skip the 'root=UUID=<...>' line as well return 0; } @@ -190,7 +203,8 @@ sub is_false_positive sub may_leak_address { my ($line) = @_; - my $address = '\b(0x)?ffff[[:xdigit:]]{12}\b'; + my $address64 = '\b(0x)?ffff[[:xdigit:]]{12}\b'; + my $address32 = '\b(0x)?[[:xdigit:]]{8}\b'; # Signal masks. if ($line =~ '^SigBlk:' or @@ -202,11 +216,23 @@ sub may_leak_address $line =~ '\b[[:xdigit:]]{14} [[:xdigit:]]{16} [[:xdigit:]]{16}\b') { return 0; } - - while (/($address)/g) { + + if ($bit_size == 64) { + while (/($address64)/g) { if (!is_false_positive($1)) { return 1; } + } + } elsif ($bit_size == 32) { + while (/($address32)/g) { + my $addr32 = eval hex($1); + if ($addr32 < $PAGE_OFFSET_32BIT) { + return 0; + } + if (!is_false_positive($addr32)) { + return 1; + } + } } return 0; scripts/leaking_addresses.pl | 40 +++++++++++++++++++++++++++++++++------- From 1583646580229944501@xxx Fri Nov 10 03:04:29 +0000 2017 X-GM-THRID: 1583410491222242898 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread