Skip to main content
added 58 characters in body
Source Link
Mike Ounsworth
  • 59.3k
  • 21
  • 162
  • 214

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle.

If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code:

if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
    retval = -EINVAL;

was turned into a backdoor like so:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

(hint: instead of checking if you're root uid == 0, it turns you into root uid = 0. So pass in the flags _WCLONE|_WALL to whatever system call this is and BAM! you're now root.)

This example isn't directly relevant, but shows that malicious code in C/C++ can be really subtle. So if you think there's a chance that someone is playing hide-and-seek games in the code, move on and find a different project.


I often deal with a softer version of your question, "Is this open source library / tool ok to use?". My approach is to see if it has a good reputation; is it actively maintained? Do their github tickets give the impression that they follow a proper dev process? Do they publish regular changelogs, including security fixes? Are theDoes it have unresolved CVEs against it? If there are binaries, are they properly code-signed? 

It's not foolproof, but it weeds out seedier projects.

(if anyone has a better way of vetting open source projects, I'd love suggestions!) (if anyone has a better way of vetting open source projects, I'd love suggestions!)

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle.

If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code:

if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
    retval = -EINVAL;

was turned into a backdoor like so:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

(hint: instead of checking if you're root uid == 0, it turns you into root uid = 0. So pass in the flags _WCLONE|_WALL to whatever system call this is and BAM! you're now root.)

This example isn't directly relevant, but shows that malicious code in C/C++ can be really subtle. So if you think there's a chance that someone is playing hide-and-seek games in the code, move on and find a different project.


I often deal with a softer version of your question, "Is this open source library / tool ok to use?". My approach is to see if it has a good reputation; is it actively maintained? Do their github tickets give the impression that they follow a proper dev process? Do they publish regular changelogs, including security fixes? Are the binaries properly code-signed? It's not foolproof, but it weeds out seedier projects.

(if anyone has a better way of vetting open source projects, I'd love suggestions!)

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle.

If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code:

if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
    retval = -EINVAL;

was turned into a backdoor like so:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

(hint: instead of checking if you're root uid == 0, it turns you into root uid = 0. So pass in the flags _WCLONE|_WALL to whatever system call this is and BAM! you're now root.)

This example isn't directly relevant, but shows that malicious code in C/C++ can be really subtle. So if you think there's a chance that someone is playing hide-and-seek games in the code, move on and find a different project.


I often deal with a softer version of your question, "Is this open source library / tool ok to use?". My approach is to see if it has a good reputation; is it actively maintained? Do their github tickets give the impression that they follow a proper dev process? Do they publish regular changelogs, including security fixes? Does it have unresolved CVEs against it? If there are binaries, are they properly code-signed? 

It's not foolproof, but it weeds out seedier projects. (if anyone has a better way of vetting open source projects, I'd love suggestions!)

Source Link
Mike Ounsworth
  • 59.3k
  • 21
  • 162
  • 214

If you want to be 100% sure that some git repo doesn't contain malicious code, write it yourself; anything else will be an uphill battle.

If someone's really truly trying to hide malicious code in plain sight, then you probably won't notice it. Take for example, the infamous 2003 nearly-a-backdoor in the Linux kernel where this harmless code:

if ((options == (__WCLONE|__WALL)) && (current->uid == 0))
    retval = -EINVAL;

was turned into a backdoor like so:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    retval = -EINVAL;

(hint: instead of checking if you're root uid == 0, it turns you into root uid = 0. So pass in the flags _WCLONE|_WALL to whatever system call this is and BAM! you're now root.)

This example isn't directly relevant, but shows that malicious code in C/C++ can be really subtle. So if you think there's a chance that someone is playing hide-and-seek games in the code, move on and find a different project.


I often deal with a softer version of your question, "Is this open source library / tool ok to use?". My approach is to see if it has a good reputation; is it actively maintained? Do their github tickets give the impression that they follow a proper dev process? Do they publish regular changelogs, including security fixes? Are the binaries properly code-signed? It's not foolproof, but it weeds out seedier projects.

(if anyone has a better way of vetting open source projects, I'd love suggestions!)