Admin privileges aren't the same thing as a kernel-mode driver. Steam does require admin to be installed, but it does not install a kernel-mode driver.
This would be true if the only alternative to piracy is not using said content or software. If paying is a valid alternative to a nonzero fraction of pirate users if piracy was not an option, then the piracy does affect the creators economically.
Maybe that would be obvious to the average Apple user, but as a non-Apple user, it would never occur to me that I'd have to explicitly de-register my phone number with Apple after activating a new phone.
There was a time after you still needed to have the iPhone to do it, though. And I'm not sure how many are actually aware you have to do this, just getting messages for them sent into the void.
> Doesn't work for me in the Netherlands. Down since this morning.
Same for me. It is accessible from my home network (AS206238) and from public transport wifi (AS202189), but not from any other network I can currently access (AS201975, AS50266).
> * I want to call my friend in Germany. What time is it for her? I guess I'm UTC-7 and she's UTC+1, so she's 8 hours ahead of me. I know that everybody around the world typically wakes up between 6 and 9 AM and goes to sleep between 8 PM and midnight, and she's an early bird, so she should be awake.
> Without timezones:
> * I want to call my friend in Germany. It's the same time here as there. It rises at 13:00 here, but she's a quarter of the way way around the world. I have to look up their typical waking hours. She's an early bird, so is she on the early side of that, likely. What time does the sun rise there? How much does that change over the seasons?
This is actually the same thing. In both cases you have to know or look up that there's an 8 hour difference between the two of you.
The bits about the seasons and being an early bird apply equally to both cases, so it's not really relevant to the comparison.
It is not the same thing. I do not need to reason at all right now, I just look at the clock that shows times in relevant timezones. I know all the information instantly, without any calculations in head at all.
In the latter case, you do need to do math, because what you are getting is meaningless number and then you need to convert it to some kind of "how long after typical start of day" format to get information you actually want.
Ah, so you're saying you have a clock showing German time, and it did the "math" for you.
Imagine multiple world clocks, in the typical Hollywood command bunker look. Instead of each clock having hour hands pointing in different directions, they'd all have the same hour hand position, but different highlighted zones for waking hours (or "shift 1", "shift 2", "shift 3", for 24h duty).
> In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, password_verify() function may accept some invalid Blowfish hashes as valid. If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid.
One scenario would be setting another user’s password to the invalid hash so they can continue to log in with their existing password, and you can also log in without knowing that password.
PHP is the king of SQL injections, they are often not too hard to come by on a lot of deployments. Sure, if you use modern PHP with modern toolkits/frameworks/libraries and you follow OWASP and are a competent developer, you might never introduce such vulnerabilities in your codebase. But PHP didn't gain popularity because it had frameworks that were concerned about security or that it had a trove of security conscious developers - it thrived because any 13 year old could string together a website that was as minimum of a viable product as possible.
If you have a sql injection vulnerability they literally already have the keys to the castle. This in addition gets you nothing you didn’t already have simply by setting the hash to a known value.
How would you persistently log into another user’s account, without them knowing anything was wrong and without knowing their password, with just sql injection?
Well i kind of agree with you that the covert persistence aspect makes this a borderline low severity bug, but pivoting from DB->access isn't exactly unheard of.
I would first of all, wonder why i would want that. Why access someone's account when i could just dump the DB. Obviously it depends on context, but most of the time, DB access is more valuable than account access.
I would check if the DB is misconfigured (e.g. In mysql, does the DB user have File or Super rights?)
I would dump all the passwords and see if anyone's is weak enough to suffer from a crack attempt
I would check if there is anything in the DB that looks like php serialized data (People are saying unfair things about PHP like it being the king of sql injection, but its probably fair to say that unsafe deserialization is pretty common in php).
As a last resort, i would check if there is anything that looks like HTML or JS in the database, and see if i could get an XSS to leverage into an account take over.
True, but in this case if you can write an invalid hash into a database, you can likewise write a valid one, and as such this doesn't really enable anything.
The one thing this does get you is that the original password would still work (technically any password would still work) so it may make it harder to detect since the user wouldn't "suddenly be locked out"...
There are scenarios, but they are pretty out there.
For example, a service might import hashed passwords from a directory, and an attacker has limited influence on the network connection to cause some random-ish data corruption.
> Like, its a really interesting security adjacent bug, but clearly not a security issue.
I kinda disagree. We often think of security in layers, and an unexpected fail-open behavior in any layer should be treated as a (potential) security issue.
The impact might be low because you expect another layer (like protection of the password database) to prevent exploits, but there could always be corner cases where that assumption doesn't hold 100%, especially in something as fundamental as a language built-in, a system call or something like that.
So IMHO it's pretty low severity, but still a security issue.
In effect all bugs are security bugs. When people offer an excuse, what they're telling you is that they don't care about correctness, which in turn means they don't actually care about security only about appearances.
Why are all bugs security bugs? Because security depends on the actual behaviour of the software, and bugs cause this behaviour to deviate from your intended and documented behaviour in unknown ways which means they have unknown impact on security. Figuring out whether any user of the software actually incurs a security impact as a result of any particular bug is likely to be far more work than fixing it, so just fix it.
The equivalent of an argument that everything causes cancer => smoking is fine would be all bugs are security bugs => don't bother fixing the bug underpinning a known a remote code execution exploit.
Which is not at all what I was getting at. Again, don't spend time trying to argue why this or that bug is probably fine actually and not "really" a security problem, fix it and then it isn't.
> If the attacker has the ability to set a hash, they can just set the hash to a known password.
That requires the attacker top also have access to the salt
I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways". This is not entirely true. Think a gateway service that lets the user to something on another service with access without access to the database immediately giving access to the system.
Nope. Blowfish doesn’t use a manually defined salt. It generates one itself randomly every time and includes it in the hash result string which you generally store the entire string in the database. No secret salt involved.
> That requires the attacker top also have access to the salt
Which you must presume they do. If any part of your security relies on the salt being secret, that's a much bigger vulnerability than this.
That said, I do think there's a potential vulnerability here, because it allows you to break in if you can only corrupt another user's password hash (rather than controlling it entirely). Think a rowhammer attack or something.
Again, not necessarily. This depends on the hashing scheme you use. Eg. if setting a correct password hash relies on you having access to private keys.
There isn't enough renewable energy yet to cover all consumption. Which means that you paying extra is only an administrative move. You're just swapping places with the party that would otherwise have consumed the renewable energy.
In my experience it's quite the opposite. We use Flask for a large-scale webapp in production quite successfully and it's enabled us to reduce application complexity significantly.
Money isn't stored in other assets. It's transferred from the buyer of an asset to the seller. It doesn't cease to exist simply because you traded it for stocks (or gold or anything else). Now the seller has to deal with the consequences of holding the money you previously held. A rational trader factors in the costs of money when they price assets, therefore one doesn't avoid those costs by trading money for other assets.
Right, and so the seller then has to put that money back in the market in some other asset at marginally higher prices, lest they lose money to inflation holding it in cash (or fixed-denomination assets).
This is the natural consequence of negative real interest rates. With positive rates the infinite series representing the "discounted value of all future cash flows" converges to a single dollar value. With negative rates the series diverges: the "discounted value" of future cash flows is greater than their nominal value, simply because you're losing money with competing investments. The rational value of any investment that generates positive and predictable cash flows becomes infinite.
Right now the only thing holding a lid on equity valuations is the expectation that the Fed will eventually raise rates, and so cash flows from time periods > 2023 need to be discounted at positive rates. If that doesn't happen, or if they don't raise rates by more than the inflation rate at the time, things will go boom.
Two economists are sitting at a bar, one pulls out a checkbook and writes a check for $100,000,000 then hands it to the other economist. The second economist looks at the check, smiles, then hands it back.
The first economist calls the bartender over and orders a bottle of champagne. The bartender asks what the celebration is about, and the economist responds, "we just grew GDP by $200 million dollars."
