ninegunpi

tl;dr: Balancing tradeoffs and benefits during disclosure is a hard job sometimes and if authors chosen to do it this way - they could have done it for a reason? You don't have to trust me on this, but it has no commercial agenda behind it.

Disclaimer: I happen to work at the same company as authors, not involved in writing this, but I was witness to all research that led to this post. I have seen huge internal arguments on how much and how should be disclosed, given the context (see below), prior to this article being written.

1. I can attest that all these bugs are found in one physical device. I have seen it. Which is really widely used to this day. Moreover, this device has more relatives than we could easily enumerate, some of them potentially vulnerable to a subset of the bugs identified as well. The "vendor" is aware and nothing is changing for a while, in some ways getting worse (blast radius increases over time). This is result of economic reasons, rather than negligence,- "the vendor" in this case is a mixed bag of responsibility between several parties, not all of them commercial, not all of them actually existing to this very date, I believe.

2. In a normal situation, responsible disclosure path, instead of what you've been reading in a post, would be a right way to go. However, context matters in this case: authors happen to live in a country which is at war now (takes like 5 seconds to figure out, looking at the website), so their ability to talk about security vulnerabilities is a bit different to your expectations for reasons that are not very hard to understand. They use vague language, distort a few important details and focus on frivolous illustrations to avoid unnecessary damage.

Pointing out practical exploitability vectors publicly in a way that is understandable to anyone related to the field of practice is sufficiently helpful:

* Some people will now have explanations why their toy cars were stolen and consider changing their supplier of toy car equipment.

* Some people conducting engineering risk analysis will understand that this is not a "potential theoretical vulnerability", looking at their toy car and some of its settings, and consider alternatives.

Consider blog post and examples to be didactic material for an ongoing discussion about some hardware among field practitioners. Authors needed something to point their fingers at and say "this is how X can be exploited to do Y", without reading 2 hours lecture on cryptographic bugs that have been obvious 15 years ago.

3. Why not point out vendor and device list? Consider the context again, please.

It's easy to wave your hand and say "if people are idiots using hardware and devices that are known to be vulnerable, we should let them screw themselves", disclose the name of the vendor, and go on with your life. However:

* Being pointed out directly, these vulnerabilities could easily lead not only to "market levelling out discrepancies" (which does not always happen harmlessly, as we all know). It could lead to more physical damage and deaths immediately happening around authors of this post because exploitation is so easy.

* Not making it would lead to these devices being used over and over again, and obvious cryptographic bugs being dismissed as "theoretical threats", because remote toy car community is full of "Internet of Stuff" people who are dismissing cryptographic vulnerabilities on basis of "it's crypto, who knows how to exploit it, we've got more important stuff to worry about right now".

Infosec emotional climate always had a certain pessimistic, paranoid and panicky perception from the outside, but it is greatly exaggerated, I think.

FUD, bullshit, lack of skilled people, lack of budgets, lack of understanding from adjacent departments, chaos, mayhem, overtimes, incidents and creeping "I'm not sure what's going on" have always been parts of the profession. Learning to accept frustration, constant change, ill-formed perception and rejection is part of your career choice and a selection factor in the long term. Learning to look at the world from a certain angle which is hard to unlearn (especially if you're good at it) is a mental equivalent of firefighter's calluses.

If you can bear with it all - being on defensive side and being a kind of digital first responder (regardless of where exactly you are in the industry) is a fun job and calling for some.

(Edits: Typos)

Love cryptopals beyond my ability to articulate it well enough. This is monumental work many engineers owe their “cryptography 101-404” education to.

For a long while company I work for used Cryptopals as means to train/qualify interns before letting them touch serious practical stuff.

Not that knowing answers is a problem (there were public solutions, albeit clunky, before), but such careful explanation almost eliminates the fun in solving to some extent.

Gotta come up with our own take w/o public tour now, is anyone aware of any similar sets of challenges? CryptoHack is ok, but fairly deterministic one that removes “oh where do I go now” feeling, which is essential to bear with to learn to love the craft.

Edits: typos.

To scale shipping static content, I'd rather look into CDN with proper caching, instead of maintaining ten layers of abstraction just to feel good about how modern my stack is.

Isn't RASP just slapping the WAF-like signature detection into your application data streams directly? How would RASP prevent:

1. Insiders having access to database front?

2. Same SQL bypass techniques as employed to bypass WAFs?

3. Mitigate developer errors in query logic which enable custom injections?

If your security strategy relies on one or two security controls, you're doomed most of the time.

We've added SQL filtering as a defense-in-depth measure, having a convenient seat in the architecture, complementing every other mitigation measure proper application developers and DBAs should be doing (and frequently get wrong).

Even ORMs get bypassed once in a while:

- https://github.com/mysqljs/mysql/issues/342 - https://github.com/sequelize/sequelize/issues/5671 - (okay, we can avoid this one by saying nothing "nothing proper exists in NodeJS world) https://bertwagner.com/2018/03/06/2-5-ways-your-orm-will-all...

Dumb concatenation can nullify the merit of quite advanced ORM: copybook example of misusing Ruby's ActiveRecord (is that proper enough) got as far as OWASP testing guide: https://www.owasp.org/index.php/Testing_for_ORM_Injection_(O...

Prepared statements are cooked wrong as well, but rarely, that's why they are viable line of defense, but not the sole one (as nothing should be):

https://www.reddit.com/r/netsec/comments/ww9qm/sqli_bypassin... https://stackoverflow.com/questions/134099/are-pdo-prepared-...

(in fact, I've seen with my eyes exactly what first comment in reddit postmentions).

I actually came to comment on this matter. Anecdotal evidence of several people I know is that playing FPS games with trackpad (pretty much of a torture) improves touchpad intuitive usage to an extent where they don't notice any discomfort with it in daily life.

Perhaps, hand-eye coordianation training that happens in FPS shooters translates to better touchpad usage in normal cases.

(Still, I'm told that trying to competitively play FPS games with it just sucks).

What you are describing is effectively two aspects of the first step of traditional buddhist meditation Shamatha - awareness on chosen object and awareness on present signals of the body, so yes, meditation is is.

>We may never be able to build a machine that can recognize the full diversity of human emotional experience

Even humans have a lot of problems recognizing full diversity of their own emotional experience, unless trained appropriately.

You've made far better one than me below. Hats off.

1. A "quite a while" is less than a hundred years after Godel and in math? Compared to 2000+ years of Aristotlean logic dominance in hard sciences just because Romans inherited most of their scientific views from Greeks, not from Indians/Chinese?

2. It depends on domains of applicability, if you think of it.

In pure CS and math? Yes, the visible value is limited, because most problems we choose to try to solve can be solved with math apparatus we're armed with. Value I know is mostly limited to optimizing problems that have poor solutions with binary logic.

In practical engineering? ATPG, to my understanding, requires multi-valued logic. Analysis of large phenomena and automated decision making becomes an order of magnitude simpler problems, with better efficiency over chosen metric. Temperature controllers, decisions based on photo-metering (autofocus, exposure adjustment), etc. Somehow, even with lack of readily-available building blocks and tooling, it turns out that there are problems people are motivated to solve from scratch, and MVL/FL comes handy.

It's only stuff I overheard of through my life among bright engineers.

3. Moreover, the biggest impact is not in CS (as original presented paradox isn't, as well), it's on human judgment, decision-making and general assessment of reality, where "neither true nor false" (I don't know) is the first stepping stone to make the world much easier place to live in.

Indeed. Yet, it is still based on True/False pair, which does not reflect neither reality or human experience in most cases. Where it is applicable - it perfectly works. But the scope is limited.

Descendants of Aristotle still find limitations of the system amusing, that’s amusing itself.

I hope to live to the day when philosophical advancements of 20th century (or re-discovery of 2500-old Indian logic, if you like), formalized in accessible forms, get widespread acceptance, could leave plenty of people who’se job it to juggle limited abstractions with the need to pick more useful jobs.

No pun intended, these are terribly useful abstractions we’ve built our world on, but they barely hold up against thorough reality check and leave out a lot as ‘paradoxes’.

1. The problem is that most population is terribly poor at defining and managing risk, by biological design and social selection - those who are good at it are usually not the best neighbors you want to have.

2. In many businesses, the actual customers are not the end-users, whose data is leaked (all the nice free services you're getting over this invisible thing called internet), they are the merchandise business is selling to somebody else (ads, etc.).

3. There are two ways of coping with this:

3.1 darwinian, where stupid users who choose to hand their data to dumb businesses all jump off the cliff holding hands

3.2 paternalistic, where we elect somebody competent to make choices for the rest of the community, which would prevent people's poor judgment to both hand data to insecure businesses and for businesses to be insecure in the first place.

4. We tried darwinian one since the day 1 in many fields. Reverting it comes at cost (antibiotics would be one good example to think of).

You are correct. I get a bit irritated when somebody claims to teach developers "all they need to know about cryptography" and goes on with explaining things they'd be happy to obsess on, instead of explaining things they _need to know_ to use cryptography securely.

These two pages themselves are important enough, these omissions are bad enough to disqualify any other effort in this book - cryptography is a tightly-knit system and making one or two mistakes simply nullifies the effect of making hundreds of correct decisions.

There are books on the subject which get it right, this is not the one.

It's like teaching people chinese gymnastics and saying it will protect you on the street - sooner or later someone has to punch you in the face for that.

Opened the book, read first random page (https://cryptobook.nakov.com/key-exchange/diffie-hellman-key...), closed the book.

If this is what "developers need to know", then explaining why anonymous key exchange is susceptible to MiTM and what can we do about it (PKI/CA/prior key exchange) would be way more useful than providing background of how DHKE actually works (there are way better explanations than repeating copybook examples anyway).

Upd: out of sheer curiosity, opened second page. https://cryptobook.nakov.com/symmetric-key-ciphers/cipher-bl.... Can we at least teach developers about nonce/IV challenges in GCM before saying it's "is highly recommended in the general case"? Perhaps, spending some page length on encrypt-then-sign, sign-then-encrypt and sign-encrypt-MAC merits would be more helpful to developers than CTR block scheme?

It would be terribly interesting to hear what some of the brighter minds here think about CS security model.

In fact, due to browser execution model, it’s not impractical - it’s impossible - it can mutate any moment.

I do get your arguments very well: having to advocate ZKPP primitive in our own solution I end in discussions about ‘ZKPP does not prevent brute force’ a lot. But it’s unfair to rule out the analysis because this is a choice - these are weaknesses, they are making the system weaker. The fact that you’re providing ibcremental security in many spheres of your influence does not mean that, when being questioned, they are atill weak against practical risks. ‘Secure against chosen threat model’ is OK when threat model reflects reality, paper’s author, I think, is coming not from basis of your threat models, but from basis of security challenges of modern e-mail.

Quite frequently the difference between what you want to protect against vs real threat landscape is what rules the expert community’s decision.

I feel your pain (I work at company which improves data security of distributed systems in a number of ways, and get into similar disputes all the time), but the fact that you’re mitigating some of the risks really well does not mean that other security properties will not be scrutinized against commonly recognized threat models.

Not too rewarding, yet the whole security engineering is a Sysiphus’ labor fron day 0. Not having enough of in-community pressure (even when sometimes you’re criticized for a wrong cause, which is 50/50 here) would lead to much worse consequences than a few uncomfortable questions asked.

There are good general observations on e2e claims for any web app (5.1 and part of conclusions section), which apply to almost any web app, aside from design flaws in the protonmail itself.

with good general observations on web app trust as a whole as a bonus (section 5.1).

Background in infrastructure is the best you can have - you will be far ahead compared to many newly educated ‘security engineers’, knowing the application domain.

What I would think about if I were you (was so 15 years ago - started as systems engineer in telco, although has been playing around with systems since childhood) is to try and capitalize on knowledge you’ve got - pick entrypoint to secuirty market as ‘security for X’, where X is the type of systems you’ve been administrating. This way, you’ll have a solid base of problem domain experience, and will be able to easily associate new learning material and new work challenges with experience you’ve already got.

Security is a huge domain of knowledge - being able to bite it with digestible chunks is crucial not to turn into another checklist drone or certified skript kiddie.