More Bad News: Your Wifi Can Become a Radar System to Map Its Area

In his blog, Bruce Schneier brings attention to the fact that a Wifi system can be used like radar: to map out the space it occupies.

This has an obvious military application, and it could easily be abused in a totalitarian state.

If the concerned general user is trying to decide between LAN or wireless for an internet connection, this fact of radar mapping is just one more factor that tells us to choose LAN.

It has long been known that the waves coming from a Wifi can be manipulated with other waves from an active attack–for various purposes.

Again, this is just one more reason to choose a hard-wired connection for a non-air-gapped system.



The U.S. Senate has Decided to Use Signal

The U.S. Senate has decided to protect its personal communications:  who says they cannot get anything done!  It means the someone in the Senate is aware of what is going on with collection. After all this time since Snowden spilled the beans, someone with a pulse and a living brain cell has decided to encrypt. Too bad they could not have done that for the Office of Personnel Management before the Chinese robbed the cookie jar, with glee and amused contempt.

No one likes being spied upon, and at this very moment one can bet that collection devices belonging to several countries are filling up with data from Senate devices. That task just got harder.

But don’t think for one moment that Signal actually works once it is used. The math is probably good, but the employment is surely prone to defeat. The idea of Signal is solid and convincing, its math is like the Titanic, but…

There are some good jokes hanging in the air. Remember how the CIA was spying on Diane Feinstein? Diane Feinstein, a lady who was very willing to allow spying on anyone and everyone in the U.S. –except herself. Now it will be harder for the the deep state to spy on the Senate, and we should all applaud that. We are moving towards a bright future, as President Obama used to say, with a straight face, “Moving forward…” (which is, by definition, not backward).


This was a response on Bruce Schneier’s thought-provoking and informative blog:

Linux-based OS as Fundamentally Unsecure


“Right now the Linux kernel has a huge number of poorly tested (from a security standpoint) interfaces and a lot of them are enabled and exposed to unprivileged users in popular Linux distributions like Ubuntu.”



Project Zero

News and updates from the Project Zero team at Google

Wednesday, May 10, 2017

Exploiting the Linux kernel via packet sockets

Guest blog post, posted by Andrey Konovalov


Lately I’ve been spending some time fuzzing network-related Linux kernel interfaces with syzkaller. Besides the recently discovered vulnerability in DCCP sockets, I also found another one, this time in packet sockets. This post describes how the bug was discovered and how we can exploit it to escalate privileges.

The bug itself (CVE-2017-7308) is a signedness issue, which leads to an exploitable heap-out-of-bounds write. It can be triggered by providing specific parameters to the PACKET_RX_RING option on an AF_PACKET socket with a TPACKET_V3 ring buffer version enabled. As a result the following sanity check in the packet_set_ring() function in net/packet/af_packet.c can be bypassed, which later leads to an out-of-bounds access.

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     (int)(req->tp_block_size –

4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)

4210                         goto out;

The bug was introduced on Aug 19, 2011 in the commit f6fb8f10 (“af-packet: TPACKET_V3 flexible buffer implementation”) together with the TPACKET_V3 implementation. There was an attempt to fix it on Aug 15, 2014 in commit dc808110 (“packet: handle too big packets for PACKET_V3”) by adding additional checks, but this was not sufficient, as shown below. The bug was fixed in 2b6867c2 (“net/packet: fix overflow in check for priv area size”) on Mar 29, 2017.

The bug affects a kernel if it has AF_PACKET sockets enabled (CONFIG_PACKET=y), which is the case for many Linux kernel distributions. Exploitation requires the CAP_NET_RAW privilege to be able to create such sockets. However it’s possible to do that from a user namespace if they are enabled (CONFIG_USER_NS=y) and accessible to unprivileged users.

Since packet sockets are a quite widely used kernel feature, this vulnerability affects a number of popular Linux kernel distributions including Ubuntu and Android. It should be noted, that access to AF_PACKET sockets is expressly disallowed to any untrusted code within Android, although it is available to some privileged components. Updated Ubuntu kernels are already out, Android’s update is scheduled for July.


The bug was found with syzkaller, a coverage guided syscall fuzzer, and KASAN, a dynamic memory error detector. I’m going to provide some details on how syzkaller works and how to use it for fuzzing some kernel interface in case someone decides to try this.

Let’s start with a quick overview of how the syzkaller fuzzer works. Syzkaller is able to generate random programs (sequences of syscalls) based on manually written template descriptions for each syscall. The fuzzer executes these programs and collects code coverage for each of them. Using the coverage information, syzkaller keeps a corpus of programs, which trigger different code paths in the kernel. Whenever a new program triggers a new code path (i.e. gives new coverage), syzkaller adds it to the corpus. Besides generating completely new programs, syzkaller is able to mutate the existing ones from the corpus.

Syzkaller is meant to be used together with dynamic bug detectors like KASAN (detects memory bugs like out-of-bounds and use-after-frees, available upstream since 4.0), KMSAN (detects uses of uninitialized memory, prototype was just released) or KTSAN (detects data races, prototype is available). The idea is that syzkaller stresses the kernel and executes various interesting code paths and the detectors detect and report bugs.

The usual workflow for finding bugs with syzkaller is as follows:

  1. Setup syzkaller and make sure it works. README and wiki provides quite extensive information on how to do that.
  2. Write template descriptions for a particular kernel interface you want to test.
  3. Specify the syscalls that are used in this interface in the syzkaller config.
  4. Run syzkaller until it finds bugs. Usually this happens quite fast for the interfaces, that haven’t been tested with it previously.

Syzkaller uses it’s own declarative language to describe syscall templates. Checkout sys/sys.txt for an example or sys/ for the information on the syntax. Here’s an excerpt from the syzkaller descriptions for AF_PACKET sockets that I used to discover the bug:

resource sock_packet[sock]

define ETH_P_ALL_BE htons(ETH_P_ALL)

socket$packet(domain const[AF_PACKET], type flags[packet_socket_type], proto const[ETH_P_ALL_BE]) sock_packet

packet_socket_type = SOCK_RAW, SOCK_DGRAM

setsockopt$packet_rx_ring(fd sock_packet, level const[SOL_PACKET], optname const[PACKET_RX_RING], optval ptr[in, tpacket_req_u], optlen len[optval])

setsockopt$packet_tx_ring(fd sock_packet, level const[SOL_PACKET], optname const[PACKET_TX_RING], optval ptr[in, tpacket_req_u], optlen len[optval])

tpacket_req {

tp_block_size int32

tp_block_nr int32

tp_frame_size int32

tp_frame_nr int32


tpacket_req3 {

tp_block_size int32

tp_block_nr int32

tp_frame_size int32

tp_frame_nr int32

tp_retire_blk_tov int32

tp_sizeof_priv int32

tp_feature_req_word int32


tpacket_req_u [

req tpacket_req

req3 tpacket_req3

] [varlen]

The syntax is mostly self-explanatory. First, we declare a new type sock_packet. This type is inherited from an existing type sock. That way syzkaller will use syscalls which have arguments of type sock on sock_packet sockets as well.

After that, we declare a new syscall socket$packet. The part before the $ sign tells syzkaller what syscall it should use, and the part after the $ sign is used to differentiate between different kinds of the same syscall. This is particularly useful when dealing with syscalls like ioctl. The socket$packet syscall returns a sock_packet socket.

Then setsockopt$packet_rx_ring and setsockopt$packet_tx_ring are declared. These syscalls set the PACKET_RX_RING and PACKET_TX_RING socket options on a sock_packet socket. I’ll talk about these options in details below. Both of them use the tpacket_req_u union as a socket option value. This union has two struct members tpacket_req and tpacket_req3.

Once the descriptions are added, syzkaller can be instructed to fuzz packet-related syscalls specifically. This is what I provided in the syzkaller manager config:

“enable_syscalls”: [

“socket$packet”, “socketpair$packet”, “accept$packet”, “accept4$packet”, “bind$packet”, “connect$packet”, “sendto$packet”, “recvfrom$packet”, “getsockname$packet”, “getpeername$packet”, “listen”, “setsockopt”, “getsockopt”, “syz_emit_ethernet”


After a few minutes of running syzkaller with these descriptions I started getting kernel crashes. Here’s one of the syzkaller programs that triggered the mentioned bug:

mmap(&(0x7f0000000000/0xc8f000)=nil, (0xc8f000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
r0 = socket$packet(0x11, 0x3, 0x300)
setsockopt$packet_int(r0, 0x107, 0xa, &(0x7f000061f000)=0x2, 0x4)
setsockopt$packet_rx_ring(r0, 0x107, 0x5, &(0x7f0000c8b000)=@req3={0x10000, 0x3, 0x10000, 0x3, 0x4, 0xfffffffffffffffe, 0x5}, 0x1c)

And here’s one of the KASAN reports. It should be noted, that since the access is quite far past the block bounds, allocation and deallocation stacks don’t correspond to the overflown object.


BUG: KASAN: slab-out-of-bounds in prb_close_block net/packet/af_packet.c:808

Write of size 4 at addr ffff880054b70010 by task syz-executor0/30839

CPU: 0 PID: 30839 Comm: syz-executor0 Not tainted 4.11.0-rc2+ #94

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011

Call Trace:

__dump_stack lib/dump_stack.c:16 [inline]

dump_stack+0x292/0x398 lib/dump_stack.c:52

print_address_description+0x73/0x280 mm/kasan/report.c:246

kasan_report_error mm/kasan/report.c:345 [inline]

kasan_report.part.3+0x21f/0x310 mm/kasan/report.c:368

kasan_report mm/kasan/report.c:393 [inline]

__asan_report_store4_noabort+0x2c/0x30 mm/kasan/report.c:393

prb_close_block net/packet/af_packet.c:808 [inline]

prb_retire_current_block+0x6ed/0x820 net/packet/af_packet.c:970

__packet_lookup_frame_in_block net/packet/af_packet.c:1093 [inline]

packet_current_rx_frame net/packet/af_packet.c:1122 [inline]

tpacket_rcv+0x9c1/0x3750 net/packet/af_packet.c:2236

packet_rcv_fanout+0x527/0x810 net/packet/af_packet.c:1493

deliver_skb net/core/dev.c:1834 [inline]

__netif_receive_skb_core+0x1cff/0x3400 net/core/dev.c:4117

__netif_receive_skb+0x2a/0x170 net/core/dev.c:4244

netif_receive_skb_internal+0x1d6/0x430 net/core/dev.c:4272

netif_receive_skb+0xae/0x3b0 net/core/dev.c:4296

tun_rx_batched.isra.39+0x5e5/0x8c0 drivers/net/tun.c:1155

tun_get_user+0x100d/0x2e20 drivers/net/tun.c:1327

tun_chr_write_iter+0xd8/0x190 drivers/net/tun.c:1353

call_write_iter include/linux/fs.h:1733 [inline]

new_sync_write fs/read_write.c:497 [inline]

__vfs_write+0x483/0x760 fs/read_write.c:510

vfs_write+0x187/0x530 fs/read_write.c:558

SYSC_write fs/read_write.c:605 [inline]

SyS_write+0xfb/0x230 fs/read_write.c:597


RIP: 0033:0x40b031

RSP: 002b:00007faacbc3cb50 EFLAGS: 00000293 ORIG_RAX: 0000000000000001

RAX: ffffffffffffffda RBX: 000000000000002a RCX: 000000000040b031

RDX: 000000000000002a RSI: 0000000020002fd6 RDI: 0000000000000015

RBP: 00000000006e2960 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000708000

R13: 000000000000002a R14: 0000000020002fd6 R15: 0000000000000000

Allocated by task 30534:

save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59

save_stack+0x43/0xd0 mm/kasan/kasan.c:513

set_track mm/kasan/kasan.c:525 [inline]

kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617

kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555

slab_post_alloc_hook mm/slab.h:456 [inline]

slab_alloc_node mm/slub.c:2720 [inline]

slab_alloc mm/slub.c:2728 [inline]

kmem_cache_alloc+0x1af/0x250 mm/slub.c:2733

getname_flags+0xcb/0x580 fs/namei.c:137

getname+0x19/0x20 fs/namei.c:208

do_sys_open+0x2ff/0x720 fs/open.c:1045

SYSC_open fs/open.c:1069 [inline]

SyS_open+0x2d/0x40 fs/open.c:1064


Freed by task 30534:

save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59

save_stack+0x43/0xd0 mm/kasan/kasan.c:513

set_track mm/kasan/kasan.c:525 [inline]

kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590

slab_free_hook mm/slub.c:1358 [inline]

slab_free_freelist_hook mm/slub.c:1381 [inline]

slab_free mm/slub.c:2963 [inline]

kmem_cache_free+0xb5/0x2d0 mm/slub.c:2985

putname+0xee/0x130 fs/namei.c:257

do_sys_open+0x336/0x720 fs/open.c:1060

SYSC_open fs/open.c:1069 [inline]

SyS_open+0x2d/0x40 fs/open.c:1064


Object at ffff880054b70040 belongs to cache names_cache of size 4096

The buggy address belongs to the page:

page:ffffea000152dc00 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0

flags: 0x500000000008100(slab|head)

raw: 0500000000008100 0000000000000000 0000000000000000 0000000100070007

raw: ffffea0001549a20 ffffea0001b3cc20 ffff88003eb44f40 0000000000000000

page dumped because: kasan: bad access detected

Memory state around the buggy address:

ffff880054b6ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ffff880054b6ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

>ffff880054b70000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb


ffff880054b70080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

ffff880054b70100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb


You can find more details about syzkaller in it’s repository and more details about KASAN in the kernel documentation. If you decide to try syzkaller or KASAN and run into any troubles drop an email to or to

Introduction to AF_PACKET sockets

To better understand the bug, the vulnerability it leads to and how to exploit it, we need to understand what AF_PACKET sockets are and how they are implemented in the kernel.


AF_PACKET sockets allow users to send or receive packets on the device driver level. This for example lets them to implement their own protocol on top of the physical layer or to sniff packets including Ethernet and higher levels protocol headers. To create an AF_PACKET socket a process must have the CAP_NET_RAW capability in the user namespace that governs its network namespace. More details can be found in the packet sockets documentation. It should be noted that if a kernel has unprivileged user namespaces enabled, then an unprivileged user is able to create packet sockets.

To send and receive packets on a packet socket, a process can use the send and recv syscalls. However, packet sockets provide a way to do this faster by using a ring buffer, that’s shared between the kernel and the userspace. A ring buffer can be created via the PACKET_TX_RING and PACKET_RX_RING socket options. The ring buffer can then be mmaped by the user and the packet data can then be read or written directly to it.

There are a few different variants of the way the ring buffer is handled by the kernel. This variant can be chosen by the user by using the PACKET_VERSION socket option. The difference between ring buffer versions can be found in the kernel documentation (search for “TPACKET versions”).

One of the widely known users of AF_PACKET sockets is the tcpdump utility. This is roughly what happens when tcpdump is used to sniff all packets on a particular interface:

# strace tcpdump -i eth0

socket(PF_PACKET, SOCK_RAW, 768)        = 3

bind(3, {sa_family=AF_PACKET, proto=0x03, if2, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0

setsockopt(3, SOL_PACKET, PACKET_VERSION, [1], 4) = 0

setsockopt(3, SOL_PACKET, PACKET_RX_RING, {block_size=131072, block_nr=31, frame_size=65616, frame_nr=31}, 16) = 0

mmap(NULL, 4063232, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f73a6817000

This sequence of syscalls corresponds to the following actions:

  1. A socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) is created.
  2. The socket is bound to the eth0 interface.
  3. Ring buffer version is set to TPACKET_V2 via the PACKET_VERSION socket option.
  4. A ring buffer is created via the PACKET_RX_RING socket option.
  5. The ring buffer is mmapped in the userspace.

After that the kernel will start putting all packets coming through the eth0 interface in the ring buffer and tcpdump will read them from the mmapped region in the userspace.

Ring buffers

Let’s see how to use ring buffers for packet sockets. For consistency all of the kernel code snippets below will come from the Linux kernel 4.8. This is the version the latest Ubuntu 16.04.2 kernel is based on.

The existing documentation mostly focuses on TPACKET_V1 and TPACKET_V2 ring buffer versions. Since the mentioned bug only affects the TPACKET_V3 version, I’m going to assume that we deal with that particular version for the rest of the post. Also I’m going to mostly focus on PACKET_RX_RING ignoring PACKET_TX_RING.

A ring buffer is a memory region used to store packets. Each packet is stored in a separate frame. Frames are grouped into blocks. In TPACKET_V3 ring buffers frame size is not fixed and can have arbitrary value as long as a frame fits into a block.

To create a TPACKET_V3 ring buffer via the PACKET_RX_RING socket option a user must provide the exact parameters for the ring buffer. These parameters are passed to the setsockopt call via a pointer to a request struct called tpacket_req3, which is defined as:

274 struct tpacket_req3 {

275         unsigned int    tp_block_size;  /* Minimal size of contiguous block */

276         unsigned int    tp_block_nr;    /* Number of blocks */

277         unsigned int    tp_frame_size;  /* Size of frame */

278         unsigned int    tp_frame_nr;    /* Total number of frames */

279         unsigned int    tp_retire_blk_tov; /* timeout in msecs */

280         unsigned int    tp_sizeof_priv; /* offset to private data area */

281         unsigned int    tp_feature_req_word;

282 };

Here’s what each field means in the tpacket_req3 struct:

  1. tp_block_size – the size of each block.
  2. tp_block_nr – the number of blocks.
  3. tp_frame_size – the size of each frame, ignored for TPACKET_V3.
  4. tp_frame_nr – the number of frames, ignored for TPACKET_V3.
  5. tp_retire_blk_tov – timeout after which a block is retired, even if it’s not fully filled with data (see below).
  6. tp_sizeof_priv – the size of per-block private area. This area can be used by a user to store arbitrary information associated with each block.
  7. tp_feature_req_word – a set of flags (actually just one at the moment), which allows to enable some additional functionality.

Each block has an associated header, which is stored at the very beginning of the memory area allocated for the block. The block header struct is called tpacket_block_desc and has a block_status field, which indicates whether the block is currently being used by the kernel or available to the user. The usual workflow is that the kernel stores packets into a block until it’s full and then sets block_status to TP_STATUS_USER. The user then reads required data from the block and releases it back to the kernel by setting block_status to TP_STATUS_KERNEL.

186 struct tpacket_hdr_v1 {

187         __u32   block_status;

188         __u32   num_pkts;

189         __u32   offset_to_first_pkt;

233 };


235 union tpacket_bd_header_u {

236         struct tpacket_hdr_v1 bh1;

237 };


239 struct tpacket_block_desc {

240         __u32 version;

241         __u32 offset_to_priv;

242         union tpacket_bd_header_u hdr;

243 };

Each frame also has an associated header described by the struct tpacket3_hdr. The tp_next_offset field points to the next frame within the same block.

162 struct tpacket3_hdr {

163         __u32 tp_next_offset;

176 };

When a block is fully filled with data (a new packet doesn’t fit into the remaining space), it’s closed and released to userspace or “retired” by the kernel. Since the user usually wants to see packets as soon as possible, the kernel can release a block even if it’s not filled with data completely. This is done by setting up a timer that retires current block with a timeout controlled by the tp_retire_blk_tov parameter.

There’s also a way so specify per-block private area, which the kernel won’t touch and the user can use to store any information associated with a block. The size of this area is passed via the tp_sizeof_priv parameter.

If you’d like to better understand how a userspace program can use TPACKET_V3 ring buffer you can read the example provided in the documentation (search for “TPACKET_V3 example“).

Implementation of AF_PACKET sockets

Let’s take a quick look at how some of this is implemented in the kernel.

Struct definitions

Whenever a packet socket is created, an associated packet_sock struct is allocated in the kernel:

103 struct packet_sock {

105         struct sock             sk;

108         struct packet_ring_buffer       rx_ring;

109         struct packet_ring_buffer       tx_ring;

123         enum tpacket_versions   tp_version;

130         int                     (*xmit)(struct sk_buff *skb);

132 };

The tp_version field in this struct holds the ring buffer version, which in our case is set to TPACKET_V3 by a PACKET_VERSION setsockopt call. The rx_ring and tx_ring fields describe the receive and transmit ring buffers in case they are created via PACKET_RX_RING and PACKET_TX_RING setsockopt calls. These two fields have type packet_ring_buffer, which is defined as:

56 struct packet_ring_buffer {

57         struct pgv              *pg_vec;

70         struct tpacket_kbdq_core        prb_bdqc;

71 };

The pg_vec field is a pointer to an array of pgv structs, each of which holds a reference to a block. Blocks are actually allocated separately, not as a one contiguous memory region.

52 struct pgv {

53         char *buffer;

54 };

The prb_bdqc field is of type tpacket_kbdq_core and its fields describe the current state of the ring buffer:

14 struct tpacket_kbdq_core {

21         unsigned short  blk_sizeof_priv;

36         char            *nxt_offset;

49         struct timer_list retire_blk_timer;

50 };

The blk_sizeof_priv fields contains the size of the per-block private area. The nxt_offset field points inside the currently active block and shows where the next packet should be saved. The retire_blk_timer field has type timer_list and describes the timer which retires current block on timeout.

12 struct timer_list {

17         struct hlist_node       entry;

18         unsigned long           expires;

19         void                    (*function)(unsigned long);

20         unsigned long           data;

31 };

Ring buffer setup

The kernel uses the packet_setsockopt() function to handle setting socket options for packet sockets. When the PACKET_VERSION socket option is used, the kernel sets po->tp_version to the provided value.

With the PACKET_RX_RING socket option a receive ring buffer is created. Internally it’s done by the packet_set_ring() function. This function does a lot of things, so I’ll just show the important parts. First, packet_set_ring() performs a bunch of sanity checks on the provided ring buffer parameters:

4202                 err = -EINVAL;

4203                 if (unlikely((int)req->tp_block_size <= 0))

4204                         goto out;

4205                 if (unlikely(!PAGE_ALIGNED(req->tp_block_size)))

4206                         goto out;

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     (int)(req->tp_block_size –

4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)

4210                         goto out;

4211                 if (unlikely(req->tp_frame_size < po->tp_hdrlen +

4212                                         po->tp_reserve))

4213                         goto out;

4214                 if (unlikely(req->tp_frame_size & (TPACKET_ALIGNMENT – 1)))

4215                         goto out;


4217                 rb->frames_per_block = req->tp_block_size / req->tp_frame_size;

4218                 if (unlikely(rb->frames_per_block == 0))

4219                         goto out;

4220                 if (unlikely((rb->frames_per_block * req->tp_block_nr) !=

4221                                         req->tp_frame_nr))

4222                         goto out;

Then, it allocates the ring buffer blocks:

4224                 err = -ENOMEM;

4225                 order = get_order(req->tp_block_size);

4226                 pg_vec = alloc_pg_vec(req, order);

4227                 if (unlikely(!pg_vec))

4228                         goto out;

It should be noted that alloc_pg_vec() uses the kernel page allocator to allocate blocks (we’ll use this in the exploit):

4104 static char *alloc_one_pg_vec_page(unsigned long order)

4105 {

4110         buffer = (char *) __get_free_pages(gfp_flags, order);

4111         if (buffer)

4112                 return buffer;

4127 }


4129 static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)

4130 {

4139         for (i = 0; i < block_nr; i++) {

4140                 pg_vec[i].buffer = alloc_one_pg_vec_page(order);

4143         }

4152 }

Finally, packet_set_ring() calls init_prb_bdqc(), which performs some additional steps to set up a TPACKET_V3 receive ring buffer specifically:

4229                 switch (po->tp_version) {

4230                 case TPACKET_V3:

4234                         if (!tx_ring)

4235                                 init_prb_bdqc(po, rb, pg_vec, req_u);

4236                         break;

4237                 default:

4238                         break;

4239                 }

The init_prb_bdqc() function copies provided ring buffer parameters to the prb_bdqc field of the ring buffer struct, calculates some other parameters based on them, sets up the block retire timer and calls prb_open_block() to initialize the first block:

604 static void init_prb_bdqc(struct packet_sock *po,

605                         struct packet_ring_buffer *rb,

606                         struct pgv *pg_vec,

607                         union tpacket_req_u *req_u)

608 {

609         struct tpacket_kbdq_core *p1 = GET_PBDQC_FROM_RB(rb);

610         struct tpacket_block_desc *pbd;

616         pbd = (struct tpacket_block_desc *)pg_vec[0].buffer;

617         p1->pkblk_start = pg_vec[0].buffer;

618         p1->kblk_size = req_u->req3.tp_block_size;

630         p1->blk_sizeof_priv = req_u->req3.tp_sizeof_priv;


632         p1->max_frame_len = p1->kblk_size – BLK_PLUS_PRIV(p1->blk_sizeof_priv);

633         prb_init_ft_ops(p1, req_u);

634         prb_setup_retire_blk_timer(po);

635         prb_open_block(p1, pbd);

636 }

On of the things that the prb_open_block() function does is it sets the nxt_offset field of the tpacket_kbdq_core struct to point right after the per-block private area:

841 static void prb_open_block(struct tpacket_kbdq_core *pkc1,

842         struct tpacket_block_desc *pbd1)

843 {

862         pkc1->pkblk_start = (char *)pbd1;

863         pkc1->nxt_offset = pkc1->pkblk_start + BLK_PLUS_PRIV(pkc1->blk_sizeof_priv);

876 }

Packet reception

Whenever a new packet is received, the kernel is supposed to save it into the ring buffer. The key function here is __packet_lookup_frame_in_block(), which does the following:

  1. Checks whether the currently active block has enough space for the packet.
  2. If yes, saves the packet to the current block and returns.
  3. If no, dispatches the next block and saves the packet there.

1041 static void *__packet_lookup_frame_in_block(struct packet_sock *po,

1042                                             struct sk_buff *skb,

1043                                                 int status,

1044                                             unsigned int len

1045                                             )

1046 {

1047         struct tpacket_kbdq_core *pkc;

1048         struct tpacket_block_desc *pbd;

1049         char *curr, *end;


1051         pkc = GET_PBDQC_FROM_RB(&po->rx_ring);

1052         pbd = GET_CURR_PBLOCK_DESC_FROM_CORE(pkc);

1075         curr = pkc->nxt_offset;

1076         pkc->skb = skb;

1077         end = (char *)pbd + pkc->kblk_size;


1079         /* first try the current block */

1080         if (curr+TOTAL_PKT_LEN_INCL_ALIGN(len) < end) {

1081                 prb_fill_curr_block(curr, pkc, pbd, len);

1082                 return (void *)curr;

1083         }


1085         /* Ok, close the current block */

1086         prb_retire_current_block(pkc, po, 0);


1088         /* Now, try to dispatch the next block */

1089         curr = (char *)prb_dispatch_next_block(pkc, po);

1090         if (curr) {

1091                 pbd = GET_CURR_PBLOCK_DESC_FROM_CORE(pkc);

1092                 prb_fill_curr_block(curr, pkc, pbd, len);

1093                 return (void *)curr;

1094         }

1101 }



Let’s look closely at the following check from packet_set_ring():

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     (int)(req->tp_block_size –

4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)

4210                         goto out;

This is supposed to ensure that the length of the block header together with the per-block private data is not bigger than the size of the block. Which totally makes sense, otherwise we won’t have enough space in the block for them let alone the packet data.

However turns out this check can be bypassed. In case req_u->req3.tp_sizeof_priv has the higher bit set, casting the expression to int results in a big positive value instead of negative. To illustrate this behavior:

A = req->tp_block_size = 4096 = 0x1000

B = req_u->req3.tp_sizeof_priv = (1 << 31) + 4096 = 0x80001000

BLK_PLUS_PRIV(B) = (1 << 31) + 4096 + 48 = 0x80001030

A – BLK_PLUS_PRIV(B) = 0x1000 – 0x80001030 = 0x7fffffd0

(int)0x7fffffd0 = 0x7fffffd0 > 0

Later, when req_u->req3.tp_sizeof_priv is copied to p1->blk_sizeof_priv in init_prb_bdqc() (see the snippet above), it’s clamped to two lower bytes, since the type of the latter is unsigned short. So this bug basically allows us to set the blk_sizeof_priv of the tpacket_kbdq_core struct to arbitrary value bypassing all sanity checks.


If we search through the net/packet/af_packet.c source looking for blk_sizeof_priv usage, we’ll find that it’s being used in the two following places.

The first one is in init_prb_bdqc() right after it gets assigned (see the code snippet above) to set max_frame_len. The value of p1->max_frame_len denotes the maximum size of a frame that can be saved into a block. Since we control p1->blk_sizeof_priv, we can make BLK_PLUS_PRIV(p1->blk_sizeof_priv) bigger than p1->kblk_size. This will result in p1->max_frame_len having a huge value, higher than the size of a block. This allows us to bypass the size check when a frame is being copied into a block, thus causing a kernel heap out-of-bounds write.

That’s not all. Another user of blk_sizeof_priv is prb_open_block(), which initializes a block (the code snippet is above as well). There pkc1->nxt_offset denotes the address, where the kernel will write a new packet when it’s being received. The kernel doesn’t intend to overwrite the block header and per-block private data, so it makes this address to point right after them. Since we control blk_sizeof_priv, we can control the lowest two bytes of nxt_offset. This allows us to control offset of the out-of-bounds write.

To sum up, this bug leads to a kernel heap out-of-bounds write of controlled maximum size and controlled offset up to about 64k bytes.


Let’s see how we can exploit this vulnerability. I’m going to be targeting x86-64 Ubuntu 16.04.2 with 4.8.0-41-generic kernel version with KASLR, SMEP and SMAP enabled. Ubuntu kernel has user namespaces available to unprivileged users (CONFIG_USER_NS=y and no restrictions on it’s usage), so the bug can be exploited to gain root privileges by an unprivileged user. All of the exploitation steps below are performed from within a user namespace.

The Linux kernel has support for a few hardening features that make exploitation more difficult. KASLR (Kernel Address Space Layout Randomization) puts the kernel text at a random offset to make jumping to a particular fixed address useless. SMEP (Supervisor Mode Execution Protection) causes an oops whenever the kernel tries to execute code from the userspace memory and SMAP (Supervisor Mode Access Prevention) does the same whenever the kernel tries to access the userspace memory directly.

Shaping heap

The idea of the exploit is to use the heap out-of-bounds write to overwrite a function pointer in the memory adjacent to the overflown block. For that we need to specifically shape the heap, so some object with a triggerable function pointer is placed right after a ring buffer block. I chose the already mentioned packet_sock struct to be this object. We need to find a way to make the kernel allocate a ring buffer block and a packet_sock struct one next to the other.

As I mentioned above, ring buffer blocks are allocated with the kernel page allocator (buddy allocator). It allows to allocate blocks of 2^n contiguous memory pages. The allocator keeps a freelist of such block for each n and returns the freelist head when a block is requested. If the freelist for some n is empty, it finds the first m > n, for which the freelist is not empty and splits it in halves until the required size is reached. Therefore, if we start repeatedly allocating blocks of size 2^n, at some point they will start coming from one high order memory block being split and they will be adjacent each one to the next.

A packet_sock is allocated via the kmalloc() function by the slab allocator. The slab allocator is mostly used to allocate objects of a smaller-than-one-page size. It uses the page allocator to allocate a big block of memory and splits this block into smaller objects. The big blocks are called slabs, hence the name of the allocator. A set of slabs together with their current state and a set of operations like “allocate an object” and “free an object” is called a cache. The slab allocator creates a set of general purpose caches for objects of size 2^n. Whenever kmalloc(size) is called, the slab allocator rounds size up to the nearest power of 2 and uses the cache of that size.

Since the kernel uses kmalloc() all the time, if we try to allocate an object it will most likely come from one of the slabs already created during previous usage. However, if we start allocating objects of the same size, at some point the slab allocator will run out of slabs for this size and will have to allocate another one via the page allocator.

The size of a newly allocated slab depends on the size of objects this slab is meant for. The size of the packet_sock struct is ~1920 and 1024 < 1920 <= 2048, which means that it’ll be rounded to 2048 and the kmalloc-2048 cache will be used. Turns out, for this particular cache the SLUB allocator (which is the kind of slab allocator used in Ubuntu) uses slabs of size 0x8000. So whenever the allocator runs out of slabs for the kmalloc-2048 cache, it allocates 0x8000 bytes with the page allocator.

Keeping all that in mind, this is how we can allocate a kmalloc-2048 slab next to a ring buffer block:

  1. Allocate a lot (512 worked for me) of objects of size 2048 to fill currently existing slabs in the kmalloc-2048 cache. To do that we can create a bunch of packet sockets to cause allocation of packet_sock structs.
  2. Allocate a lot (1024 worked for me) page blocks of size 0x8000 to drain the page allocator freelists and cause some high-order page block to be split. To do that we can create another packet socket and attach a ring buffer with 1024 blocks of size 0x8000.
  3. Create a packet socket and attach a ring buffer with blocks of size 0x8000. The last one of these blocks (I’m using 2 blocks, the reason is explained below) is the one we’re going to overflow.
  4. Create a bunch of packet sockets to allocate packet_sock structs and cause an allocation of at least one new slab.

This way we can shape the heap in the following way:

The exact number of allocations to drain freelists and shape the heap the way we want might be different for different setups and depend on the memory usage activity. The numbers above are for a mostly idle Ubuntu machine.

Controlling the overwrite

Above I explained that the bug results in a write of a controlled maximum size at a controlled offset out of the bounds of a ring buffer block. Turns out not only we can control the maximum size and offset, we can actually control the exact data (and it’s size) that’s being written. Since the data that’s being stored in a ring buffer block is the packet that’s passing through a particular network interface, we can manually send packets with arbitrary content on a raw socket through the loopback interface. If we’re doing that in an isolated network namespace no external traffic will interfere.

There are a few caveats though.

First, it seems that the size of a packet must be at least 14 bytes (12 bytes for two mac addresses and 2 bytes for the EtherType apparently) for it to be passed to the packet socket layer. That means that we have to overwrite at least 14 bytes. The data in the packet itself can be arbitrary.

Then, the lowest 3 bits of nxt_offset always have the value of 2 due to the alignment. That means that we can’t start overwriting at an 8-byte aligned offset.

Besides that, when a packet is being received and saved into a block, the kernel updates some fields in the block and frame headers. If we point nxt_offset to some particular offset we want to overwrite, some data where the block and frames headers end up will probably be corrupted.

Another issue is that if we make nxt_offset point past the block end, the first block will be immediately closed when the first packet is being received, since the kernel will (correctly) decide that there’s no space left in the first block (see the __packet_lookup_frame_in_block() snippet). This is not really an issue, since we can create a ring buffer with 2 blocks. The first one will be closed, the second one will be overflown.

Executing code

Now, we need to figure out which function pointers to overwrite. There are a few of function pointers fields in the packet_sock struct, but I ended up using the following two:

  1. packet_sock->xmit
  2. packet_sock->rx_ring->prb_bdqc->retire_blk_timer->func

The first one is called whenever a user tries to send a packet via a packet socket. The usual way to elevate privileges to root is to execute the commit_creds(prepare_kernel_cred(0)) payload in a process context. The xmit pointer is called from a process context, which means we can simply point it to the executable memory region, which contains the payload.

To do that we need to put our payload to some executable memory region. One of the possible ways for that is to put the payload in the userspace, either by mmapping an executable memory page or by just defining a global function within our exploit program. However, SMEP & SMAP will prevent the kernel from accessing and executing user memory directly, so we need to deal with them first.

For that I used the retire_blk_timer field (the same field used by Philip Pettersson in his CVE-2016-8655 exploit). It contains a function pointer that’s triggered whenever the retire timer times out. During normal packet socket operation, retire_blk_timer->func points to prb_retire_rx_blk_timer_expired() and it’s called with retire_blk_timer->data as an argument, which contains the address of the packet_sock struct. Since we can overwrite the data field along with the func field, we get a very nice func(data) primitive.

The state of SMEP & SMAP on the current CPU core is controlled by the 20th and 21st bits of the CR4 register. To disable them we should zero out these two bits. For this we can use the func(data) primitive to call native_write_cr4(X), where X has 20th and 21st bits set to 0. The exact value of X might depend on what other CPU features are enabled. On the machine where I tested the exploit, the value of CR4 is 0x10407f0 (only the SMEP bit is enabled since the CPU has no SMAP support), so I used X = 0x407f0. We can use the sched_setaffinity syscall to force the exploit program to be executed on one CPU core and thus making sure that the userspace payload will be executed on the same core as where we disable SMAP & SMEP.

Putting this all together, here are the exploitation steps:

  1. Figure out the kernel text address to bypass KASLR (described below).
  2. Pad heap as described above.
  3. Disable SMEP & SMAP.
    1. Allocate a packet_sock after a ring buffer block.
    2. Schedule a block retire timer on the packet_sock by attaching a receive ring buffer to it.
    3. Overflow the block and overwrite retire_blk_timer field. Make retire_blk_timer->func point to native_write_cr4 and make retire_blk_timer->data equal to the desired CR4 value.
    4. Wait for the timer to be executed, now we have SMEP & SMAP disabled on the current core.
  4. Get root privileges.
    1. Allocate another pair of a packet_sock and a ring buffer block.
    2. Overflow the block and overwrite xmit field. Make xmit point to a commit_creds(prepare_kernel_cred(0)) allocated in userspace.
    3. Send a packet on the corresponding packet socket, xmit will get triggered and the current process will obtain root privileges.

The exploit code can be found here.

It should be noted, that when we overwrite these two fields in the packet_sock structs, we’ll end up corrupting some of the fields before them (the kernel will write some values to the block and frame headers), which can lead to a kernel crash. However, as long as these other fields don’t get used by the kernel we should be good. I found that one of the fields that caused crashes if we try to close all packet sockets after the exploit finished is the mclist field, but simply zeroing it out helps.

KASLR bypass

I didn’t bother to come up with some elaborate KASLR bypass technique which exploits the same bug. Since Ubuntu doesn’t restrict dmesg by default, we can just grep the kernel syslog for the “Freeing SMP” string, which contains a kernel pointer, that looks suspiciously similar to the kernel text address:

# Boot #1

$ dmesg | grep ‘Freeing SMP’

[    0.012520] Freeing SMP alternatives memory: 32K (ffffffffa58ee000 – ffffffffa58f6000)

$ sudo cat /proc/kallsyms | grep ‘T _text’

ffffffffa4800000 T _text

# Boot #2

$ dmesg | grep ‘Freeing SMP’

[    0.017487] Freeing SMP alternatives memory: 32K (ffffffff85aee000 – ffffffff85af6000)

$ sudo cat /proc/kallsyms | grep ‘T _text’

ffffffff84a00000 T _text

By doing simple math we can calculate the kernel text address based on the one exposed through dmesg. This way of figuring out the kernel text location works only for some time after boot, as syslog only stores a fixed number of lines and starts dropping them at some point.

There are a few Linux kernel hardening features that can be used to prevent this kind of information disclosures. The first one is called dmesg_restrict and it restricts the ability of unprivileged users to read the kernel syslog. It should be noted, that even with dmesg restricted the first user on Ubuntu can still read the syslog from /var/log/kern.log and /var/log/syslog since he belongs to the adm group.

Another feature is called kptr_restrict and it doesn’t allow unprivileged users to see pointers printed by the kernel with the %pK format specifier. However in 4.8 the free_reserved_area() function uses %p, so kptr_restrict doesn’t help in this case. In 4.10 free_reserved_area() was fixed not to print address ranges at all, but the change was not backported to older kernels.


Let’s take a look at the fix. The vulnerable code as it was before the fix is below. Remember that the user fully controls both tp_block_size and tp_sizeof_priv.

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     (int)(req->tp_block_size –

4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv)) <= 0)

4210                         goto out;

When thinking about a way to fix this, the first idea that comes to mind is that we can compare the two values as is without that weird conversion to int:

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     req->tp_block_size <=

4209                           BLK_PLUS_PRIV(req_u->req3.tp_sizeof_priv))

4210                         goto out;

Funny enough, this doesn’t actually help. The reason is that an overflow can happen while evaluating BLK_PLUS_PRIV in case tp_sizeof_priv is close to the unsigned int maximum value.

177 #define BLK_PLUS_PRIV(sz_of_priv) \

178         (BLK_HDR_LEN + ALIGN((sz_of_priv), V3_ALIGNMENT))

One of the ways to fix this overflow is to cast tp_sizeof_priv to uint64 before passing it to BLK_PLUS_PRIV. That’s exactly what I did in the fix that was sent upstream.

4207                 if (po->tp_version >= TPACKET_V3 &&

4208                     req->tp_block_size <=

4209                           BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv))

4210                         goto out;


Creating packet socket requires the CAP_NET_RAW privilege, which can be acquired by an unprivileged user inside a user namespaces. Unprivileged user namespaces expose a huge kernel attack surface, which resulted in quite a few exploitable vulnerabilities (CVE-2017-7184, CVE-2016-8655, …). This kind of kernel vulnerabilities can be mitigated by completely disabling user namespaces or disallowing using them to unprivileged users.

To disable user namespaces completely you can rebuild your kernel with CONFIG_USER_NS disabled. Restricting user namespaces usage only to privileged users can be done by writing 0 to /proc/sys/kernel/unprivileged_userns_clone in Debian-based kernel. Since version 4.9 the upstream kernel has a similar /proc/sys/user/max_user_namespaces setting.


Right now the Linux kernel has a huge number of poorly tested (from a security standpoint) interfaces and a lot of them are enabled and exposed to unprivileged users in popular Linux distributions like Ubuntu. This is obviously not good and they need to be tested or restricted.

Syzkaller is an amazing tool that allows to test kernel interfaces via fuzzing. Even adding barebone descriptions for another syscall usually uncovers numbers of bugs. We certainly need people writing syscall descriptions and fixing existing ones, since there’s a huge surface that’s still not covered and probably a ton of security bugs buried in the kernel. If you decide to contribute, we’ll be glad to see a pull request.


Just a bunch of related links.




Our Linux kernel bug finding tools:

A collection of Linux kernel exploitation materials:

We Like Linux, But…

Linux is nice for an air-gapped system.  Linux is nice for a system connected to the internet.

But let’s not start thinking that we can actually secure an internet-connected Linux-based operating system.  It is just not going to happen–that is, absolute security is not possible.

That said, we can play the losing game a little and give our internet-connected OS some attention.  It is like you own a house.  You can protect it from rats.  But don’t think you can protect it from STASI 4.0 or a pimply-faced genius in Novosibirsk.

What you can protect is a device that never touches the internet.

If you think all Linux-based operating systems are utterly or even mostly secure because they are Linux-based, that is mistaken.  Linux-based systems might be more secure overall, compared to Windows, but they can still be attacked and subverted.

As soon as your Linux-based system touches the internet, it is no longer safe.  This is the unpleasant truth of the matter.  However, knowing the truth is a good starting point for setting up a system that offers real benefit (near-absolute security).


The Principles of NAS (Near-Absolute Security)

We must accept the fact that internet-connected devices are not securable.  If a professional wants your information, they are going to get it–if you started from a device that touches, has touched, or can itself touch, the internet.  The issue is that the end points–the devices sending and receiving, encrypting and decrypting– must be secure.  Without secure end points, encryption is easy to defeat and becomes a joke.

The internet is a gigantic collection platform whose complexity will always work in favor of criminal elements and other malicious types. We now live in an age of spying, and the spies have many advantages.  The interesting thing, on the other hand, is that it is actually easy to defeat them if one first disconnects and starts with an off-line system (genuinely air-gapped) and learns how to use encryption properly.

All guarantees of absolute security for internet users–for privacy and anonymity–are false.

But near-absolute security (NAS) can be realized if the following steps are observed:

1. Start from an air-gapped device that has never touched the internet and whose firmware is clean.  No Wifi, no network interface card, no Bluetooth, no audio/microphone jack, no hard drive, and no wireless antenna. Start from a live USB or Disc whose download was verified as to its source and its integrity.

2. Make sure the air-gapped device is physically secure

3. Encrypt off-line with unweakened encryption

4. Use a cascade of encryption and compression

-the cascade can involve different types of encryption, or different implementations of the same kind of encryption, or both.  Compression is important and should not be excluded. Good compression makes attacks much more difficult.

5. Move encrypted files one way so that the electronic trail is broken

-from safe device to unsafe internet-connected device, methods such as using a DVD-R to transport encrypted files once (and then destroy the disc) are acceptable.  Using a USB is not acceptable at all.

-moving from collection-platform-connected device to safe device is dangerous and requires attention to detail.  But it can be done. One must be careful not to transport malicious code from the collection-platform-connected device to the safe device.

6. Metacontent is erased (metadata)

-we need to stop using the word “metadata” and use the word “metacontent”

-metacontent should be erased every time a file is about to be moved

7. Use steganography or TOR for anonymity

8. Use passwords that are truly random that use at least 90 characters and are at least 36 characters long. (most keyboards have 94 characters:  26 + 26 + 10 +32)

-this is not easy to do, but it is necessary.  Patriot COMSEC has come up with a way to make it easy.

You are on the way to winning the game. Congratulations.

Now you are ready to get on a “secure” internet-connected computer and send your stuff.

Strong Passwords are Important

Take a look at this article in the Intercept:

Brute force attacks against passwords can be done by sophisticated actors (apparently).  The need for strong passwords has never been greater.

Patriot COMSEC has come up with several innovations in password management that will allow users to vastly improve their security.

An Ideal Computer Set Up: NAS

This is what real defense looks like:

For ideal security, law-abiding citizens could set up a computer in a room that has no RF on any frequency:  no cellular communications, no FM radio, no HF radio, no Wifi, etc.  The trail of electro-magnetic  waves has been broken. This is the key point for near-absolute security (NAS). We have created this neologism because absolute security is impossible.  In the world of electro-magnetic waves and computers, NAS is as good as it gets.

A simple room with no internet connection, with concrete walls, standard electric outlets, steel doors, and a ventilation system that does not let in RF, can be proven to be secure from RF by the use of a spectrometer.

In reality, building such a room underground might be the best decision.  Special attention should be given to electrical outlets and ventilation.  Certain radio waves bend, others do not. We must not allow internet connection via electrical outlet in this set up.

Inside this room, which also has good physical security, one could store private and public PGP keys and do encryption, of whatever type. One could also store encrypted files and back them up.  Encrypted files made in this room could be taken to the internet via DVD-R.  Once a DVD-R is used, it should be destroyed. Any computer that touches the internet is not secure at all. Best practice would be to get this secure room away from Wifi connections and any sources of RF as much as possible.

Who would actually need such a protected room?  Someone running a political campaign, an inventor, an important lawyer, a business negotiator, a celebrity, any important decision maker, anyone who insists on privacy. Privacy is still not illegal in most places in the world.

Sound and RF can be more difficult to eliminate than what one might think.  The angularity of the walls is designed to stop waves that bend.  For example, waves around 900 MhZ are very good at bending. The concrete walls should be at least 8 inches thick. The spectrometer is important because it will tell you if your design has worked.  Even though the design works and RF is eliminated, one should not bring a mobile device into the private room.  A mobile device inside the private room could be attacked by a malicious actor targeting that device with intense RF.  But if that happened, the spectrometer would show it immediately.  All mobile devices should be left far behind before going to the secure private area. The doors are going to be crucial in determining if RF is eliminated.  Common steel doors should be enough as long as they are properly fitted, especially on the bottom.

In real life, such a secure, private room could have many important uses:  as a storm shelter, as a place to store firearms so that they are not accessed by children, etc. If you go to the trouble of creating such a place, you might as well pay close attention to the ventilation and thickness of the walls– and make it suitable as a nuclear bomb shelter.


Using Hidden Sounds to Track Your Phone’s Location and Your Activity

According to “Privacy Threats through Ultrasonic Side Channels on Mobile Devices”, by Daniel Arp, Erwin Quiring, Christian Wressnegger and Konrad Rieck, ultrasonic side channels can be used to track mobile devices:  their location and the user’s activity.

An ultrasonic beacon is embedded in audio from a computer or internet-connected device (such as a Samsung TV), and this is used to track the location and activity of a user across different platforms.

These techniques are already being used.  One important implication of this method is the danger it presents to air-gapping.  An air-gapped computer (or mobile device–let’s call it an unmobile device) needs to be physically isolated and distant from any other device attached to the internet.  The ideal situation is one in which the air-gapped computer is in a room that cannot emit RF.  A spectrometer in that room will detect no RF whatsoever.

In practice, electronic devices within that room are likely to leak and emit a certain amount of RF when they are on.  But those frequencies will be particular each device, and it is easy to account for such RF.

Cyren’s Webinar on Hyper-evasive Malware

Cyren does impressive work for cyber defense.  They have many resources that help users understand current threats. Here is the text that introduces a webinar on extremely evasive malware:

“Threats today increasingly incorporate many known detection evasion techniques within a single piece of malware, while rarely utilizing obviously suspicious code and distributing attacks from previously unknown servers.

Such “hyper-evasive” malware is designed to evade your defenses, including traditional sandboxing, contributing to the high rate at which companies are being compromised – 71% in the past year.

View this webinar with Cyren’s top threat expert to get up to speed on the latest evasive techniques being baked into headline-making ransomware and other malware, and get insight into how your security is at risk.”