Secure keyboard
an idea by mwilck
Updated about 5 years ago. 3 hacker ♥️. Has no hacker: grab it!

This idea was inspired by the recent discussion on the "talk" mailing list about the (in)security of the German ID card. The Chaos Computer Club and other researchers claim that the ID card is insecure. Actual attacks that have been demonstrated are based on keyloggers.

Keyloggers might be the biggest security threat for Linux users at this time. Keyloggers are trivial to write for Linux and readily installable, and a keylogger with normal user rights may read root's password. One might ask "Why are we caring about local root exploits at all as long as users run stuff like sudo in X terminals"? Keyloggers can even read the input from devices like the Yubikey.

Various techniques exist. The simplest way is just to read xinput events. More sophistcated attacks (usually requiring root) would read from /dev/input or ttys.

My idea is to explore possibilities for a "secure" keyboard mode. This is all totally crude, not thought-through brainstorm material. I'm thinking of an ioctl that would put an input device in a special mode in which events would be forwarded only to a single process (the process that made the ioctl). Care would need to be taken that this functionality couldn't be abused for locking the input device completely. The ability to use this ioctl could be bound to capabilities and/or further restricted e.g. by SELinux, so that not even root would be able to spy on keyboard input easily.

This "secure" mode would than be available for critical operations such as reading pass phrases. In a second step, we might consider doing the password hashing in the kernel, so that user space would never need to read the clear text password at all; I'm not sure what problems with keyboard mapping we'd encounter in such a setup though.

I'd like to understand if this is total bogus, and if not, discuss implementation steps and perhaps create a PoC.

No Hackers yet

Join this project

Looking for hackers with the skills:

kernel c

This project is part of:

Hack Week 15

Activity

  • about 8 years ago: slahl liked this project.
  • about 8 years ago: hennevogel liked this project.
  • about 8 years ago: mwilck added keyword "kernel" to this project.
  • about 8 years ago: mwilck added keyword "c" to this project.
  • about 8 years ago: mwilck liked this project.
  • about 8 years ago: mwilck originated this project.


    • Comments

    Be the first to comment!

    Similar Projects

    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

    This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

    This project is free software and you can find it here.

    Goal for this Hackweek

    • Better understand the RISC-V SBI interface.
    • Better understand RISC-V in privileged mode.
    • Have fun.

    Resources

    Results

    The project was a resounding success add-emoji Lots of learning, and the initial target was met.

    Officially Become a Kernel Hacker! by m.crivellari

    Description

    My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

    I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

    Maybe this will be a good chance to...

    Goals

    • create my first kernel patch

    Resources

    Achivements

    Hacking on sched_ext by flonnegren

    Description

    Sched_ext upstream has some interesting issues open for grabs:

    Goals

    Send patches to sched_ext upstream

    Also set up perfetto to trace some of the example schedulers.

    Resources

    https://github.com/sched-ext/scx

    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

    One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

    For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

    Goal for this Hackweek

    Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

    Resources

    Kill DMA and DMA32 memory zones by ptesarik

    Description

    Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.

    Goals

    Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).

    Resources

    • LPC2024 talk:
    • video:

    FastFileCheck work by pstivanin

    Description

    FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.

    https://github.com/paolostivanin/FastFileCheck

    Goals

    • Release v1.0.0

    Design overwiew:

    • Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
    • Dedicated consumer thread: manages queue and distributes work to threadpool
    • Worker threads: compute hashes in parallel

    This separation of concerns is efficient because:

    • Directory traversal is I/O bound and works well in a single thread
    • Queue management is centralized, preventing race conditions
    • Hash computation is CPU-intensive and properly parallelized

    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

    This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

    This project is free software and you can find it here.

    Goal for this Hackweek

    • Better understand the RISC-V SBI interface.
    • Better understand RISC-V in privileged mode.
    • Have fun.

    Resources

    Results

    The project was a resounding success add-emoji Lots of learning, and the initial target was met.

    Add a machine-readable output to dmidecode by jdelvare

    Description

    There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

    Goals

    Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.

    ESETv2 Emulator / interpreter by m.crivellari

    Description

    ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu. The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.

    This is an example using one of their samples (it prints N Fibonacci numbers):

    .dataSize 0
.code

loadConst 0, r1 # first
loadConst 1, r2 # second

loadConst 1, r14 # loop helper

consoleRead r3

loop:
    jumpEqual end, r3, r15

    add r1, r2, r4
    mov r2, r1
    mov r4, r2

    consoleWrite r1

    sub r3, r14, r3
    jump loop
end:
hlt

    This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.

    Goals

    • create a full interpreter able to run all the available samples provided by ESET.
    • improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)

    Resources

    Achivements

    Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.