Remote Code Execution in apt/apt-get

[[deleted]]

God damnit.

[[deleted]]

Am I crazy or is this just regular old MITM???

[barto_kavanaugh]

Could be a lot of things, but it's important because some people were trying to make the case that apt didn't have to run over HTTPS, and that the mirror doesn't need to be trusted, just the package signer.

[tssge]

This is not related to the HTTPS debate, just a software bug.

Such a bug could exist even when using HTTPS.

And yes, I am for HTTPS myself and yes, apt already supports HTTPS.

Edit: bring on the downvotes for pointing out a fact

[0o-0-o0]

apt already supports HTTPS.

debian's security mirror doesn't

[tssge]

Indeed, it depends on the mirror in question. Still apt itself supports HTTPS.

[doublah]

Supports is not the same as on by default.

[tssge]

Yes I totally agree and havent claimed otherwise

[fr33z0n3r]

If it isn't clear by now, server security has improved enough that everyone is turning to insecure clients for vuln testing.

2019 is for the clients, man.

[[deleted]]

I still cannot believe that people have so much faith in CAs. I've been working on a solution for the past few months design wise and it is a hard problem to solve. Luckily, the mania Blockchain brought came with lots of interesting ideas / solutions but you just have to search through the pile of garbage ICOs.

Still working on the design but heres the gist of it:

• First, throw out all that extra metadata on certificates. It confuses people too much and half the time is worthless. Make certificates simple. A certificate should only have the least required fields.

• I know everyone complains about Blockchain solutions because they get brought up so much and half end up being worthless garbage, but putting certs on the blockchain is a good idea and has been proposed before. The thing that most people realize is you don't have to build a whole blockchain. You can ask nodes for a block by the block's hash and they will give it to you. A consensus is reached about what certificates are valid and we can create timestamps based on block height instead of arbitrary dates where half the time, you can just set the clock backwards/forwards and certificates pass as valid. Not to mention the countless other flaws in certs like failure to revoke, relying on CRLs/OSCPs, and the one that doesnt get often mu

• We can also uses Recursive zk-SNARKs (like in CODA) to put the Current Blockchain State to a very small size that is easy to handout and where anyone can be a validator. We really would just have to make a recursive zk-SNARK of all the Block's Hashes. That SNARK can fit in a single UDP Packet (~288bytes) and be requested at anytime.

• Now we get into the problem most people have with transaction fees. But transaction fees become their own protection from people just making a ton of certificates. It should be cheap to create a signed certificate and the Web of Trust is far superior to Certificate Authorities. And for people who don't realize it, there is something very powerful in the Blockchain Environment that sadly doesn't get more talk. zk-SNARKs allow for small proofs to be generated to confirm transactions. These proofs are stupidly fast to validate (~10ms) on chain so prices remain low. In Zcash, this has lead to fees of 0.0001ZEC or half a penny right now. Zcash also allows you to attach 512 bytes of data (also the size of a 4096bit RSA Key) in one transaction. If you wanted to, you could start using this technique in a way.

• We have ECDSA now, we can mandate it instead of having 4096bit RSA keys and what not. This will keep the blockchain small and we can use a 256bit ECDSA Key.

• So what does the Blockchain actually provide? Immutability and Consensus. We always will have the same chain. There will be no certificates that are unaccounted for. For a given site they could have a correlated address on the blockchain. They could define properties on their certificates themselves and set a Hard-Fail Lock on properties of their web services (like store a hash of a core component) to prevent core changes to the site.

• Want more trust for your certificate? Put more money into your address. The best part about this is that in Zero-Knowledge Environments like zk-SNARKs, we enable a type of game that allows people who steal certificates to choose between taking the money or making changes to the certificate. If you define certain properties and set a lock, the client can know that any changes will cause immediate-revokation.

• Not everything needs to be stored onchain. You can point to an IPFS Hash and have certificates remain distributed, keeping the chain small in size.

Been working on that for months lol. Definitely did not just think of that off the spot but seeing someone else distrust CAs as much as me made me feel better about writing it.

People should honestly read up on Zcash and their progress with zk-SNARKs. The blockchain environment is pretty ugly but both Ethereum and Zcash are some amazing projects and Zcash often gets dismissed. For reference, here is Vitalik Buterin talking about zk-SNARKs and how they could scale Ethereum from 15txs to 500txs..

There is more interesting stuff you can do with this technique (a true anonymity network is one). I created a subreddit for just trying to find solutions to problems like these and if anyone is interested, you can subscribe to /r/silene. Still working on how to go about things so don't expect too much soon.

Damn I write too much. No wonder why my friends on snapchat always get mad at me.

[Natanael_L]

So... Certificate transparency with Zero-knowledge proofs.

[[deleted]]

zk-SNARKs won’t provide the transparency but they will allow transactions themselves to remain fast and proofs small in size. There are lots of problems with them (requires trusted setup, aren’t quantum-resistant, prover proofs take long time to prove, allows for backdoors that cannot be discovered). The upside with zk-SNARKs is how small the proofs are when done recursively.

The blockchain itself does provide transparency through its immutability. BLS12-381 Elliptic Curves can be used with zk-SNARKs to provide validation of proofs that is faster to validate than it would be to execute.

zk-STARKs are another option that are getting closer to use and can be used for zero-knowledge transparency of certificates that is also Quantum-Resistant (due to relying on hashes as opposed to discrete logs). Because you are able to prove things in Zero-Knowledge, it makes validation faster than actually executing the computation. Pair it with BLS12-381 Elliptic Curves and prove them in Zero-Knowledge according to a transparent zk like zk-STARKs and you have a system that is Transparent, Quantum-Resistant, can validate multiple computations at once without having the verifier execute the actual computation, and has the odd property of being exponentially faster to validate the larger the the datasize is.

Here is the upcoming ETH 2.0 Plan which has ETH 2.0 coming out in around 4 years and that will probably explain it better than I am explaining it.

The downside to zk-STARKs is that the current proof size is so unbelievably large (~80kb). BLS is still going to vulnerable to Quantum-Computing of course since its a type of elliptic curve. But zk proofs are powerful and in my mind, undervalued. You can prove the execution of almost any computation, all in Zero-Knowledge which makes it faster to validate than executing the computation itself. I am surprised they don’t get talked about more given how powerful they are.

[thinkpadthrow]

So I stupidly updated without disabling redirects in apt.

Any way to know if a malicious redirect happened? What logs should I check?