In general, but also containing malware found in code belonging to the different distributions, like PKGBUILDs. I'm just thinking that part of the problem with the lack of review of AUR packages by the users is that it's not really obvious what one should be on the lookout for. What does linux malware found in the wild generally look like?, is what I'm wondering. I would think that it would benefit us all to make the cases where malware is found more easy to study.
The case shown here is pretty obvious looking, but I don't think it would be too difficult to make it better hidden. Seeing what kind of tricks are statistically more common would make PKGBUILDs easier to review.
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.
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.
In general, but also containing malware found in code belonging to the different distributions, like PKGBUILDs. I'm just thinking that part of the problem with the lack of review of AUR packages by the users is that it's not really obvious what one should be on the lookout for. What does linux malware found in the wild generally look like?, is what I'm wondering. I would think that it would benefit us all to make the cases where malware is found more easy to study.
The case shown here is pretty obvious looking, but I don't think it would be too difficult to make it better hidden. Seeing what kind of tricks are statistically more common would make PKGBUILDs easier to review.
This is one example of a kernel backdoor:
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.
1 reply →