> Sawyer is a crazy class that converts a hash to an object whose methods are based on the hash's key:
People keep adding hidden interpreters and 'exec' commands in their projects where no one expects them to be. As far as I can tell the library is just supposed to make HTTP requests, it's just a fancy client library?
This needs to be the kind of thing that developers are trained on, like "don't hash passwords" and "don't build up SQL strings from untrusted input". "Don't build your own 'exec' and hide it in your library, don't reinvent object serialization".
There is almost always a better way to solve a problem than by transmitting arbitrary code. Sometimes there isn't but it's rare, and in those cases it's very explicit ie: "I'm sending this database a query, I expect it to execute it".
The RCE here doesn't come from Sawyer `exec`ing anything. Sawyer builds objects from a hashmap, where the hashmap's properties can be accessed as method calls, recursively.
The vulnerability here arises from the fact that you can override built-in methods like `to_s`, which in combination with the way that the Redis gem builds raw commands, can be used to send arbitrary commands to Redis.
Yeah... although monkey-patching, as this bug demonstrates, can get uncomfortably close to `exec`. I have a strong distaste for monkey-patching as a result since I'm only confident in its security when it's used purely statically (i.e. no user input can change how the monkey patching happens), but then that kind of robs the entire point of monkey-patching if you remove its dynamism.
Not sure if everyone will share my definition, but I wouldn’t call this monkey-patching. Yes, it is dynamic addition of methods at runtime, but almost everything in Ruby is runtime, including method definition in the common case. So I reserve the term for when one library intrusively (and often globally) modifies the behaviour of another, i.e. some clear sense of a control boundary being crossed, which is only slightly less technical because we can still denote clear boundaries. And in this case it looks like intentional (albeit naive) behaviour within the library in question.
... And the fact that Ruby doesn’t really have fields, only methods. For example, the Python equivalent to this (morally, (obj := object()).__dict__.update(untrusted data)) would not be vulnerable. Which is not a point against Ruby, only against using this specific technique in Ruby.
I didn't mean to say it was 'exec'ing anything directly, I meant that people are reinventing 'exec' and hidden interpreters. Building up methods from runtime data is the problem I'm referring to.
As one random point: If you just hash the password, you're vulnerable to rainbow table attacks. So you want to salt the password, at the very least.
But really, what you want to do is use a framework developed by domain experts that deals with all that mess for you. Because there's a lot of surprising complexity to storing password hashes securely. So it's better to use a well-vetted library that has eyeballs and mindshare checking that it is correct.
Avoid passwords. "A secret is something you tell one other person, so I'm telling you". If possible adjust APIs to not rely on knowledge of secrets for their functioning, and then this entire problem evaporates. e.g. WebAuthn.
If it's crucial that a human memorable secret (a password) is used, choose an asymmetrical Password Authenticated Key Exchange in which it's possible for the relying party to learn a value with which they can confirm that the other party knows the password, but never learn what that password is. This is really difficult to do properly, OPAQUE is the current recommendation of the IETF for this purpose.
Only fall back to hashing passwords because you're obliged to for legacy reasons.
PAKEs bring little to the table when looked at in context of an actual threat model[1], meanwhile they add a fair degree of complexity and their implementations are much less battle-tested. Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up.
Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords".
> Don't avoid passwords with WebAuthn, either. "Fingerprints are usernames, not passwords".
It seems like you've no idea how WebAuthn works, or why it's such an important improvement. That's fine, but probably better to just tell people "I know nothing about this" rather than pretend to know enough to give a recommendation.
> PAKEs bring little to the table when looked at in context of an actual threat model
The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed.
WebAuthn can be used with or without a password. You said "avoid passwords", and mentioned WebAuthn. I simply clarified "don't avoid passwords with WebAuthn". By all means use WebAuthn, but ideally keep the password, too.
> The "threat model" your link proposes is "It's a web site". For which WebAuthn is more appropriate and covers all the issues listed.
You have correctly deduced that my comment on PAKEs was a response to your comment on PAKEs and not a criticism of WebAuthn. I believe I can say with confidence that we both think WebAuthn is great.
> By all means use WebAuthn, but ideally keep the password, too.
WebAuthn is perfectly capable of delivering two factor authentication in a single, easier to use, more secure solution. Passwords are awful, it's yet another indictment of our industry that somehow yet again a temporary hack was enshrined as a great idea. See also: people are still making new programming languages with Hoare's Billion Dollar Mistake.
If you've got WebAuthn plus a password it's like you used a padlock to secure your gate, but for some reason you also tied it shut with a shoelace. I am not going to be intimidated by the need to untie the shoelace if I've somehow broken the padlock, yet even if I can't break the padlock I can easily steal the shoelace anyway. Sites which have password + WebAuthn are secured by WebAuthn, but the user's passwords are as vulnerable as ever (to phishing, to database exposure, logging screw-ups, and so on).
The reason you might do that is legacy again, but I'm not talking about "What people might be obliged to do for legacy reasons" rather what they should strive for.
> Using them correctly won't really make anything more secure, but using them incorrectly might blow everything up.
The main benefit of PAKE is avoiding accidental logging of passwords, which absolutely happens at organizations all the time. ZKP is a fine approach, although you can avoid much of the issue with something simpler (addressing a narrower threat, but the most relevant piece).
We need flexibility because we can't predict all future needs, hence an interpreter.
An interpreter can at worst produce a denial of service. But we also want it to access our data to be useful. Giving access to exact data items it may require is hard or impossible (see flexibility), so we give it a lump of access. Hello exfiltration.
But crafting and supporting a limited interpreter is a chore. Why can't we use the perfectly good interpreter which runs our software? It's almost an RCE!
For the win, we should note that input sanitation is hard and costs us CPU, and skip it. Now finally we made enough to have our system pwned.
Here are things I would like to have in an AR/VR environment.
1. More monitors. I can only fit 2, maybe 3 monitors on my desk. If I could easily reposition 5 or 6 virtual monitors that would be great.
2. Whiteboarding. I like to draw things when I have some discussions. Doing that in VR is a pretty decent workflow.
If I could start a Slack 'huddle' with someone and instantly be able to start drawing or have us both interacting with the virtual monitors, I think that'd be enough for me to justify paying.
The tech still has to go further. For multiple monitors you'd really want to offload rendering and I think that current VR goggles are still just too heavy, they need to get cut down to maybe 20% of their current weight, at which point I think they would be comfortable enough to wear for a large portion of a workday.
The benefit of AR would be that I can seamlessly switch between "real life" workflows and "virtual" workflows. For example, I want to get up and grab some water, but I can take one of my virtual desktops along with me so that I can keep watching a conference talk or whatever.
Nothing bad? That’s the whole point of quorum reads and writes. You write to at least two, and read from at least two (one typically being a digest-only to corroborate the result).
"write will fail"...but the data will still be there (you can SELECT it normally) and will be replicated to the node that was down once it is up again.
Unless the node was down too much and could not fully catch up before a set time (DB TTL if I remember correctly), in which case the data might be propagated or not, and old deleted data might come up again and be repropagated by a cluster repair.
I know this is HN and people love to troll, but it makes me sad when I see you using falsehoods to take a steaming dump on a group of engineers that are obsessed with building a database that can scale while maintaining the highest level of correctness possible. All in Open Source... for free! Spend some time on the Cassandra mailing list and you'll walk away feeling much differently. Instead of complaining, participate. Some examples of the project's obsession with quality and correctness:
That blog was posted 9 years ago. Needless to say, a lot of improvement and engineering has happened since then. The limited use cases of LWTs will soon be replaced with general, ACID transactions.
LWTs were added for a very simple reason: stronger isolation where the performance trade-off makes sense. Nothing to do with the GP comment.
Until recently they were indeed slow over the WAN, and they remain slow under heavy contention. They are now faster than peer features for WAN reads.
However, the claim that they have many bugs needs to be backed up. I just finished overhauling Paxos in Cassandra and it is now one of the most thoroughly tested distributed consensus implementations around.
> and old deleted data might come up again and be repropagated
That pretty much describes iCloud.
Argh! Zombies!
iCloud has terrible syncing. Here’s an example. Synced bookmarks in Safari:
I use three devices, regularly; my laptop (really a desktop, most of the time), my iPad (I’m on it, now), and my iPhone.
On any one of these devices, I may choose to “favorite” a page, and add it to a fairly extensive hierarchy of bookmarks, that I prefer to keep in a Bookmarks Bar.
Each folder can have a lot of bookmarks. Most are ones that I hardly ever need to use, and I generally access them via a search.
I like to keep the “active” ones at the top of the folder. This is especially important for my iPhone, which has an extremely limited screen (it’s an iPhone 13 Mini -Alas, poor Mini. I knew him well).
The damn bookmarks keep changing order. If I drag one to the top of the menu, I do that, because it’s the most important one, and I don’t want to scroll the screen.
The issue is that the order of bookmarks changes, between devices. In fact, I just noticed that a bookmark that I dragged to the top of one of my folders, yesterday, is now back down, several notches.
Don’t get me started on deleting contacts, or syncing Messages.
I assume that this is a symptom of DB dysfunction.
You can only SELECT at QUORUM if you are guaranteed to be able to SELECT it again at QUORUM, ie it must be durable (and the QUORUM read will ensure it if the prior write did not).
If you are selecting at ONE then yes, you can expect stale replies if you contact a different node. That is what the consistency level means; that just one node has seen the write.
This is basically my guess. In the event of no mitigations you have to pessimistically flush TLB. In the case of mitigations the flush only has to happen in specific instances, which PCID significantly helps with but requires cooperation from both hardware and software.
So maybe even something like "if PCID is not set, flush the cache" vs "if PCID changes, flush the cache".
I think that would certainly account for this, and they could have improved the performance with PCID by increasing the PCID cache size.
> If it's found within your natural lifetime you will be dead before the research is complete
I'm 30. If it takes another 30 years, I'll be 60. That's late, certainly, but I could still avoid a lot of health issues if I'm able to start taking something then. Most older people I know really start to degrade around their 70s and 80s, often after some sort of health incident or chronic issue crops up.
And if not, ok, well then some younger people in a generation or two will benefit and I'm happy for them.
Interesting. I wonder if the kpti path leveraging PCID has 'tipped' into a performance improvement? Maybe a larger PCID cache on the CPUs and optimized codepaths for specter-usage?
Interesting. My only understanding of retinoids is with regards to skincare and, to my knowledge, its mode of function is essentially to increase cell turnover. Is this the same function here/ is that what accounts for this improvement?
People keep adding hidden interpreters and 'exec' commands in their projects where no one expects them to be. As far as I can tell the library is just supposed to make HTTP requests, it's just a fancy client library?
This needs to be the kind of thing that developers are trained on, like "don't hash passwords" and "don't build up SQL strings from untrusted input". "Don't build your own 'exec' and hide it in your library, don't reinvent object serialization".
There is almost always a better way to solve a problem than by transmitting arbitrary code. Sometimes there isn't but it's rare, and in those cases it's very explicit ie: "I'm sending this database a query, I expect it to execute it".