Comment by lucb1e
8 years ago
This is one example of a kernel backdoor:
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
If you haven't heard of it before, and if you're not an experienced dev, it can be tricky to spot. So what I'm trying to say is that I think you're right in that it's difficult for random people (even if they have a strong tech background) to do secure code reviews.
More info of this particular one at e.g. https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... or just search for 'linux backdoor attempt'
It's not about everyone being prepared to find malware anywhere, though, but only in the cases where they each do. For random users of AUR packages, if they (for whatever reason) trust a project's author, then they only need to check the package author's work. If they could have access to historical examples of real life malware specifically on PKGBUILD files, that would make it much easier to have an idea of what kind of details they should be on the alert for.
For kernel devs, specifically the kind that reviews patches submitted by others, I would think it would also be useful to have data on previous successful and failed attempts at introducing backdoors into the kernel.
Right now, I think that for anyone that wants to see this kind of data for any particular kind of software, they'd have to search for it through various mediums like mailing lists or the blog you linked to (through google).
That's an interesting link, by the way. Thanks for sharing.
EDIT: Removed redundant part. Misread what parent post meant.
But what's a successful backdooring attempt? Any security bug/vuln found in the kernel could have been planted. But perhaps what's what you meant, to have a database of such things, though I doubt it'll make it easier. Serious attackers would either use a custom method or look at what is rarely used on the list so it doesn't trigger any alarms.