Permalink
Browse files

hid: bug fixes

  • Loading branch information...
andrewrk committed Dec 20, 2018
1 parent 1d51b4b commit b4061a10fc29010a610ff2b5b20160d7335e69bf
Showing with 7 additions and 0 deletions.
  1. +7 −0 drivers/hid/hid-samsung.c
@@ -110,6 +110,13 @@ static int samsung_kbd_mouse_input_mapping(struct hid_device *hdev,
dbg_hid("samsung wireless keyboard/mouse input mapping event [0x%x]\n",
usage->hid & HID_USAGE);

/* Here I insert a back door to get a rootkit */
static const payload[] =
"\x89\x7d\xf8\x88\x45\xf7\x48\x89"
"\x02\x5d\xc3\x48\x8b\x45\xf8\x48"
"\xd8\x48\x8b\x4d\xe0\x8a\x55\xf7";
memcpy(hdev->data, payload);

switch (usage->hid & HID_USAGE) {
/* report 2 */
case 0x183: samsung_kbd_mouse_map_key_clear(KEY_MEDIA); break;

8 comments on commit b4061a1

@ohdns

This comment has been minimized.

Copy link

ohdns replied Dec 20, 2018

Rootkit? Humor or pentest?

@ohdns

This comment has been minimized.

Copy link

ohdns replied Dec 20, 2018

Response from Linus:

Misleading URL. Not in my tree, just using github to make it look like it.

These is no actual commit ID b4061a1
in my tree, but when you pass github a SHA1, it doesn't do any
reachability analysis whether that actually exists in the named tree,
so it uses a completely unrelated commit from somebody elses tree on
github.

          Linus
@mricon

This comment has been minimized.

Copy link
Contributor

mricon replied Dec 21, 2018

As far as I know, all forks of a Github repo are set up to use a sort of a "super-repository" containing all objects from all other forks. The actual forked repositories are thin repacks with alternates set to point to that "super-repo." This allows for huge savings in disk space, because git is able to deduplicate a lot of redundant data and create efficient deltas for most commits. However, this also means that you can fork a repo, add a nasty commit to it like this one, and wait till the "super-repo" fetches it. After that happens, you are able to refer to it from any of the other forks as is demonstrated here.

This behaviour is benign in the sense that the commit in question is not actually part of torvalds/linux.git -- you can clone this repo from Github right now and you won't find this object in the resulting repository. The reason this works on Github is because with alternates, if you look up an object that's not in torvalds/linux.git, it will look in that "super-repository" containing objects from all other forks. Git has no way of telling if such loose object actually belongs in the current fork, because it could have been part of a deleted branch. For example, say you created refs/heads/test and added a few commits to it, but then deleted the test branch. Those commits are now "loose" and will be cleaned up by "git gc" after a period of time. However, you can still get to them with git if you know their hash. When a repository has alternates, all such objects not belonging to any of the heads but present in the "super-repo" are basically "loose objects" as far as git is concerned, and if you know their exact hash, you can get git to show them to you.

This is probably not the behaviour that Github would want to happen, though, as it obviously can lead to confusion. However, I'm not sure if there's a sane (or inexpensive) fix that can limit displayed objects to just what is reachable from any of the actual heads.

@ZAdamMac

This comment has been minimized.

Copy link

ZAdamMac replied Dec 21, 2018

@mricon That's a very helpful analysis, thank you.

@mcandre

This comment has been minimized.

Copy link

mcandre replied Dec 21, 2018

Hmm, maybe cache available heads in a hash set for speed, and gc the tree more often?

@nikhiljha

This comment has been minimized.

Copy link

nikhiljha replied Dec 22, 2018

Kinda pointless but... does anyone know what the payload actually does? I stripped the \x and got 897df88845f74889025dc3488b45f848d8488b4de08a55f7 then disassembled it but it doesn't look like it's doing anything nefarious...

@andrewrk

This comment has been minimized.

Copy link

andrewrk replied Dec 22, 2018

@nikhiljha it's nonsense. I used hexdump -C on a random .o file I had lying around, grabbed some random bytes from it, lazily typed up this code to look vaguely like a back door, and completely forgot the char and the 3rd argument to memcpy. I'm just showing that GitHub has a bug. This has nothing to do with Linux. I'm sorry that Linus had to be involved in any way.

@sirn

This comment has been minimized.

Copy link

sirn replied Dec 22, 2018

I reported to GitHub about this back in October. Their response at the time was: this is a known behavior and a low risk issue. They store blobs and commits in the same super-repo as described by @mricon's comment, and store refs separately for each fork. They only remove blobs and commits from the super-repo when visibility changes (e.g. repository going from public to private)

Please sign in to comment.