4 ms·

> Compromising people is the core competency of intelligence, happens all the time, and most cases probably never come to public knowledge. Yea. It would almos

> Compromising people is the core competency of intelligence, happens all the time, and most cases probably never come to public knowledge. Yea. It would almost be strange if security service didnt consider the route of getting "kompromat" on a developer to make them "help" them.

andix 3y ago
They would be really bad at their job, if they didn't try.
- transpute 3y ago
  Developers would be really bad at their newly expanded job, if they didn't resist.
MichaelZuo 3y ago
The most secure systems are those that are also resistant to rubber hose cryptography.
- nbk_2000 3y ago
  "Rubber Hose Cryptography" comes in the form of a PR. "Rubber Hose Cryptanalysis" comes in the back door and waits for you in the dark.
  - MichaelZuo 3y ago
    No, it 'comes in the form of' a rubber hose...
nyokodo 3y ago
> consider the route of getting "kompromat" on a developer to make them "help" them I suppose that’s an option, but it also introduces an additional risk of exposure for your operation as it doesn’t always work and makes it much more complicated to manage even when it does work.
- emodendroket 3y ago
  Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”
  - andix 3y ago
    They might not even use blackmail, they might just "help out" in a difficult financial situation. Some people are in severe debt, have a gambling problem, are addicted to expensive drugs, or might need a lot of money for a sick relative. There are many possibilities. The trick is finding the people that can be compromised.
    - nyokodo 3y ago
      > They might not even use blackmail, they might just "help out" If the target knows or suspects what you’re asking them to do is nefarious then you still run the same risks that they talk before your operation is complete. It’s still far less risky to avoid tipping anyone else off and just slip a trusted asset into a project.
    - somenameforme 3y ago
      I think you're going overboard on what's required. Take anybody who is simultaneously offered a substantial monetary incentive (let's say 4 years of total current/vesting comp), and also threatened with the release of something that we'll say is little more than moderately embarrassing. And this dev is being asked to do something that stands basically 0 risks of consequences/exposure for himself due to plausible deniability. For instance, this is the heartbleed bug: "memcpy(bp, pl, payload);". You're copying (horrible naming conventions) payload bytes from pl to bp, without ensuring that the size of pl is >= payload, so an attacker can trivially get random bytes from memory. Somehow nobody caught one of the most blatant overflow vulnerabilities, even though memcpy calls are likely one of the very first places you'd check for this exact issue. Many people think it was intentional because of this, but obviously there's zero evidence, because it's basically impossible for evidence for this to exist. And so accordingly there were also 0 direct consequences, besides being in the spotlight for a few minutes and have a bunch of people ask him how it felt to be responsible for such a huge exploit. "It was a simple programming mistake" ad infinitum. So, in this context - who's going to say no? If any group, criminal or national, wanted to corrupt people - I really don't think it'd be hard at all. Mixing the carrot and the stick really changes the dynamics vs a basic blackmail thing where it's exclusively a personal loss (and with no guarantee that the criminal won't come back in 3 months to do it again). To me, the fact we've basically never had anybody come forward claiming they were a victim of such an effort means that no agency (or criminal organization) anywhere has ever tried this, or that it works essentially 100% of the time.
api 3y ago
I’m reading all this with sadness realizing that one of the Internet’s last remaining high trust spaces is being destroyed.
- transpute 3y ago
  > one of the Internet’s last remaining high trust spaces is being destroyed One of the Internet's last remaining high trust spaces is being attacked. What happens next is still unwritten.
  - api 3y ago
    From what I know of today's developer culture the solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development. Developers will say this is great and will happily invite this, with security people repeating mantras about how securing things is "hard" and "Microsoft has more security personnel than we do." Then MS will own the whole ecosystem. Anyone objecting will be called old or a paranoid nut. "This is how we do things now."
    - transpute 3y ago
      As an positive counterexample, US recently reduced federal funding for the program which manages CVEs [1]. There was/is risk of CVE data becoming pay-for-play, but OSS developers have also pushed for decentralization [2]. A recent announcement is moving in the right direction, https://medium.com/@cve_program/new-cve-record-format-enables-additional-data-fields-at-time-of-disclosure-82eef1d4035e https://medium.com/@cve_program/new-cve-record-format-enable... The CVE Board is proud to announce that the CVE Program has evolved its record format to enhance automation capabilities and data enrichment. This format, utilized by CVE Services, facilitates the reservation of CVE IDs and the inclusion of data elements like CVSS, CWE, CPE, and other data into the CVE Record at the time of issuing a security advisory. This means the authoritative source (within their CNA scope) of vulnerability information — those closest to the products themselves — can accurately report enriched data to CVE directly and contribute more substantially to the vulnerability management process. > solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development. A single vendor solution would be unacceptable to peer competitors who also depend on open-source software. A single-foundation (like LF) solution would also be sub-optimal, but at least it would be multi-vendor. Long term, we'll need a decentralized protocol for collaborative development, perhaps derived from social media protocols which support competing sources of moderation and annotation. In the meantime, one way to decentralize Github's social features is to use the GH CLI to continually export community content (e.g. issue history) as text that can be committed to a git repository for replication. Supply chain security and identity metadata can be then be layered onto collaboration data. [1] https://www.darkreading.com/vulnerabilities-threats/nist-needs-help-digging-out-of-its-vulnerability-backlog https://www.darkreading.com/vulnerabilities-threats/nist-nee... [2] https://github.com/yoctoproject/cve-cna-open-letter/blob/main/cve-cna-open-letter.txt https://github.com/yoctoproject/cve-cna-open-letter/blob/mai...

andix 3y ago

They would be really bad at their job, if they didn't try.

transpute 3y ago
Developers would be really bad at their newly expanded job, if they didn't resist.

MichaelZuo 3y ago

The most secure systems are those that are also resistant to rubber hose cryptography.

nbk_2000 3y ago
"Rubber Hose Cryptography" comes in the form of a PR. "Rubber Hose Cryptanalysis" comes in the back door and waits for you in the dark.
- MichaelZuo 3y ago
  No, it 'comes in the form of' a rubber hose...

nyokodo 3y ago

> consider the route of getting "kompromat" on a developer to make them "help" them I suppose that’s an option, but it also introduces an additional risk of exposure for your operation as it doesn’t always work and makes it much more complicated to manage even when it does work.

emodendroket 3y ago
Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”
- andix 3y ago
  They might not even use blackmail, they might just "help out" in a difficult financial situation. Some people are in severe debt, have a gambling problem, are addicted to expensive drugs, or might need a lot of money for a sick relative. There are many possibilities. The trick is finding the people that can be compromised.
  - nyokodo 3y ago
    > They might not even use blackmail, they might just "help out" If the target knows or suspects what you’re asking them to do is nefarious then you still run the same risks that they talk before your operation is complete. It’s still far less risky to avoid tipping anyone else off and just slip a trusted asset into a project.
  - somenameforme 3y ago
    I think you're going overboard on what's required. Take anybody who is simultaneously offered a substantial monetary incentive (let's say 4 years of total current/vesting comp), and also threatened with the release of something that we'll say is little more than moderately embarrassing. And this dev is being asked to do something that stands basically 0 risks of consequences/exposure for himself due to plausible deniability. For instance, this is the heartbleed bug: "memcpy(bp, pl, payload);". You're copying (horrible naming conventions) payload bytes from pl to bp, without ensuring that the size of pl is >= payload, so an attacker can trivially get random bytes from memory. Somehow nobody caught one of the most blatant overflow vulnerabilities, even though memcpy calls are likely one of the very first places you'd check for this exact issue. Many people think it was intentional because of this, but obviously there's zero evidence, because it's basically impossible for evidence for this to exist. And so accordingly there were also 0 direct consequences, besides being in the spotlight for a few minutes and have a bunch of people ask him how it felt to be responsible for such a huge exploit. "It was a simple programming mistake" ad infinitum. So, in this context - who's going to say no? If any group, criminal or national, wanted to corrupt people - I really don't think it'd be hard at all. Mixing the carrot and the stick really changes the dynamics vs a basic blackmail thing where it's exclusively a personal loss (and with no guarantee that the criminal won't come back in 3 months to do it again). To me, the fact we've basically never had anybody come forward claiming they were a victim of such an effort means that no agency (or criminal organization) anywhere has ever tried this, or that it works essentially 100% of the time.

api 3y ago

I’m reading all this with sadness realizing that one of the Internet’s last remaining high trust spaces is being destroyed.

transpute 3y ago
> one of the Internet’s last remaining high trust spaces is being destroyed One of the Internet's last remaining high trust spaces is being attacked. What happens next is still unwritten.
- api 3y ago
  From what I know of today's developer culture the solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development. Developers will say this is great and will happily invite this, with security people repeating mantras about how securing things is "hard" and "Microsoft has more security personnel than we do." Then MS will own the whole ecosystem. Anyone objecting will be called old or a paranoid nut. "This is how we do things now."
  - transpute 3y ago
    As an positive counterexample, US recently reduced federal funding for the program which manages CVEs [1]. There was/is risk of CVE data becoming pay-for-play, but OSS developers have also pushed for decentralization [2]. A recent announcement is moving in the right direction, https://medium.com/@cve_program/new-cve-record-format-enables-additional-data-fields-at-time-of-disclosure-82eef1d4035e https://medium.com/@cve_program/new-cve-record-format-enable... The CVE Board is proud to announce that the CVE Program has evolved its record format to enhance automation capabilities and data enrichment. This format, utilized by CVE Services, facilitates the reservation of CVE IDs and the inclusion of data elements like CVSS, CWE, CPE, and other data into the CVE Record at the time of issuing a security advisory. This means the authoritative source (within their CNA scope) of vulnerability information — those closest to the products themselves — can accurately report enriched data to CVE directly and contribute more substantially to the vulnerability management process. > solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development. A single vendor solution would be unacceptable to peer competitors who also depend on open-source software. A single-foundation (like LF) solution would also be sub-optimal, but at least it would be multi-vendor. Long term, we'll need a decentralized protocol for collaborative development, perhaps derived from social media protocols which support competing sources of moderation and annotation. In the meantime, one way to decentralize Github's social features is to use the GH CLI to continually export community content (e.g. issue history) as text that can be committed to a git repository for replication. Supply chain security and identity metadata can be then be layered onto collaboration data. [1] https://www.darkreading.com/vulnerabilities-threats/nist-needs-help-digging-out-of-its-vulnerability-backlog https://www.darkreading.com/vulnerabilities-threats/nist-nee... [2] https://github.com/yoctoproject/cve-cna-open-letter/blob/main/cve-cna-open-letter.txt https://github.com/yoctoproject/cve-cna-open-letter/blob/mai...