The title gives quite a different light on the content though. Doesn't count as a duplicate for me — I wouldn't have clicked the other link, but this one sure drew my attention.
Exploits can be anywhere. Just because you use only web doesn't mean that there are no usable exploits. WebKit / JSC are written in C/C++, so there are still plenty of holes to be found.
Given the frequency of exploits via WebKit/Safari (feels like a new one pops up every week, at least), is it feasible for Apple to perform a rewrite with a memory safe language?
Aren’t there tools that can analyze existing code and enforce memory safety?
I'd argue that your web browser is one of the most likely areas to be compromised from. Huge codebase, network connected, processes many different types of data, can follow links without your direction ...
> Apple patched the bugs quickly in February 2019 so everyone who has updated their iPhone since then is protected. Rebooting the iPhone wiped the malware but the data had already been taken.
Why in the world did they silently fix the issue and remove the malware? I'm fine with all of this, but shouldn't they disclose to the user "hey, some very sensitive data from your device has been taken. It is passwords, messages, etc." so that users could at least try to mitigate the impact somewhat (contact their contacts, change passwords, maybe change numbers, etc.)?
that doesn't answer the question of why didn't they go public with the information? Most people don't update frequently enough. Also some people may need to change password etc. if they've visited those sites.
That's easy, apple does not know if your specific mobile has been compromised. Also, nobody stole anything from Apple... It was a vulnerability and they provided a patch (remember that software is provided "as is")
I can't see how any software provider (ie Microsoft, Linux, Google... ) will say "install this patch to fix this and you may or may not been hacked, good luck"... They just provide the patch.
This is not a leak from a company is a leak from your device. The only one that can know if something has leaked is you.
Consider a lock manufacturer that has a key copy of each client. If someone enters in the building and steals all the keys, clearly the manufacturer should inform all their clients. But, if a vulnerability has been found in a lock model, the manufacturer can tell you about the vulnerability, but definitely they can't tell you if your house has been robbed that way (or if it has been robbed at all).
Anyway, with this story alone and without knowing if you have visited these webpages that allegedly hacked your iPhone (why aren't they listed?) the only thing you can do is renewing passwords in your most critical accounts.
They do. Every patch release contains release notes and security notes disclosing what vulnerabilities have been identified and patched. This is industry standard practice, because this is a regular occurrence on all software platforms.
It’s not big news when it happens all the time.
What is big news, that’s gotten lost in all the noise, is that Google (through it’s crawling of the web) has been able to identify that some websites were (are) indiscriminately jailbreaking iPhones for the purposes of stealing user data.
This is the kind of thing that is routine on Windows, is likely to be routine on Android (given how many unpatchable devices are in use) but wasn’t considered to be routine on iOS.
The takeaway from all this is simple: if you’re not fully patched, you’re at significant risk. It doesn’t matter which platform you use.
> I can't see how any software provider (ie Microsoft, Linux, Google... ) will say "install this patch to fix this and you may or may not been hacked, good luck"
This is part of the reason CVEs and security bulletins exist. We're being notified about potential issues all the time by many vendors.
It's bad advertising. The purpose of a corporation is to make money for stockholders, not report to you that they failed to protect you from hackers. There is no advantage to letting you know, it's much better to just fix it and push the fix and be done with it. Corporations are not moral beings, it's silly to think of them in that manner.
That's horrifying to me - I've had many phones, and never let that happen. It's bad for the battery, it's bad for the phone, it's just a bad option all around. You can't let your phone do that on a regular basis and then complain that it's slow and the battery doesn't last.
Actually it's not bad at all much less "horrifying", that's all old wives tales...
It's not bad for the phone, and whether it's bad for the battery depends on the battery technology. In fact previous battery technologies were recommending the occasional full drain!
For lithium-ion batteries the kind used in the iPhone draining to 0% can indeed strain them (though less than you think, as shown by research), but the iPhone doesn't let them go to 0% anyway. It switches off way before that (even if it shows it as 0%). Mind you that regular use cycles (defined by Apple as using 100% of a full charge, even if it's broken down as going from 100% to 80% for five days and recharging) also strains the battery. You cannot not strain it, all current technology batteries degrade over time.
Also note that getting lithium-ion batteries to 100% and keeping them charging can also harm them (although modern devices have mechanisms to prevent that). In general it's advisable to keep going from 80%-20% and back, than to go all the way to charged (or down to 0). Same, one should not store long term fully charged.
But most of this is irrelevant micromanagement unless you plan to keep your phone for years and don't ever consider replacing the battery. Even so, the battery lifespan vendors like Apple give is around 3 years of cycles.
All in all, you can fully drain your lithium-ion iPhone battery as often as the average person does (e.g. just avoid doing it all the time), and you'll see no special degradation. It will run its cycles and will degrade by regular use after a few years even if you never let it drain (and you can trivially replace it with a new one).
> Similar to a mechanical device that wears out faster with heavy use, the depth of discharge (DoD) determines the cycle count of the battery. The smaller the discharge (low DoD), the longer the battery will last. If at all possible, avoid full discharges and charge the battery more often between uses. Partial discharge on Li-ion is fine. There is no memory and the battery does not need periodic full discharge cycles to prolong life. The exception may be a periodic calibration of the fuel gauge on a smart battery or intelligent device.[1]
Why should we trust your statements over ones like these which seemingly are backed by more data and and explanations of the underlying physics?
When Apple displays the battery stats to the user it's not actually even close to 0%. That would mean you are avoiding full discharges so you're both right.
Yeah, I mention that. It works on the other side too: iPhones also won't keep batteries charging when they're at 100% so they're protected from such "trickle charging" as well.
I already covered this - that li-ion takes a hit if totally drained. The point was the degree to which this happens, that modern devices don't let it happen (the shut down much earlier, around 10% or so, so it's a moot point), and that your battery will lose capacity, anyway, due to natural cycle degradation over the course of 2-3 years.
More importantly, that such tracking is marginally useful micromanagement (and, Apple's artificial throttling for degraded batteries aside, has nothing to do with affecting a device's speed. A 90% charged device is not magically faster than a 20% charged one). Apple itself, in their document about battery technology and care ignores the "fully drain" issue completely.
I see people all the time with constant low battery phones and laptops. IDK how people live like this, but they do.
Sometimes I wonder if the windows 10 auto-update fiasco was really about people who rarely recharge; and finally charging their laptop the one time they needed to be prepared, only to get owned by Windows Update at the worst time.
You're wrong. Letting it run out isn't bad for your battery. At most you'll get an extra 10% of battery life out of the "don't go below 30% or above 80% when charging to get the best life out of your battery". I use my phone and charge it when it goes dead or when I go to sleep at night depending on usage. I regularly get 4 years or so out of my phone before switching to a new one.
Most of the people I know never turn off their phones. I'm fairly sure my parents have not done so for at least a couple of months. I wouldn't either, if not for the fact that I need to restart for updates every couple of weeks.
1) the GP quoted the part about rebooting wipes the malware. But that doesn't matter if the info was taken before the user rebooted. So this comment is really off topic.
2) the GP comment is about letting users be aware so they can help mitigate the problem and assess the threat level. For example, users need to change their passwords. If you've ever worked with any government agency their number one concern is not leak of data, but knowing what leaked (obviously they want to minimize that). Knowing what leaked is extremely important. This is what the comment is about. I don't understand how your comment addresses this.
How would they be know whether data have been indeed taken? Computers and phones (especially Android) get malware all the time, no vendor goes and informs the users...
if this is a state actor organized attack as the article implies then perhaps the target list would be very narrow and Apple wouldn't want to go into details. Or perhaps even they don't know who's infected.
The malware itself is non-persistent and doesn’t survive rebooting (typically, it would be installed in /tmp, which is a RAM file system). To survive a reboot, a piece of malware would have to somehow break the chain-of-trust extending from the boot loader (since everything is effectively revalidated on boot), which is a much smaller attack surface that is much harder to exploit.
Apple is not intentionally removing malware themselves, and AFAIK they don’t have the ability to tell if a device has been compromised.
I mean, they must have _some_ way of running code before performing an upgrade, no? So they could check for these processes, store some state on the phone, and after the upgrade display a notice about what happened. This would all be on-device so it's not even a privacy issue.
You say that like Apple knows the device was compromised. The act of patching it requires rebooting the device. Unless the malware left evidence of itself behind in persistent storage, by the time the device is patched you wouldn't be able to detect it.
I’m not yet ready to crucify Apple for not issuing a press release listing sites and services affected. Same with the Google “deep dive” with it’s vague insinuations.
I suspect this is a big international incident like - “China bought hacks from Mossad to target Hong Kong” kind of big. For all we know there are gag orders in place and an ongoing investigation.
I will still use iOS devices too. They are still the most secure consumer available/friendly computing devices available imo. That said, I want to know more.
They fix security stuff all the time. Why advertise that you failed. There's nothing to be done about it. I'm taking this point of view as a company. Telling people that you failed is not good advertising.
Seriously, it is like every second month on average a news about how insecure are different Apple products. I personally decided to go away from Apple ecosystem just after their famous "empty root password" issue was discovered. It is sometimes sounds like a joke, but their level of incompetence in software engineering is simply above any reasonable amount. If you trust your data to them, think twice.
The X server is known to be insecure, in the sense that keyloggers can steal credentials from anything else running. But in that sense no OS is particularly secure besides Qubes OS.
The discussion was on phones, there the issues are mostly core Android's lack of updates from manufacturers (but quite good record of Google releasing patches) vs iOS's closed-source buggy OS.
IDK, security is hard. The easiest solution is to get a nice clay brick and smash whatever phone you have to pieces.
No one's saying that there are no exploits, only an idiot would assume otherwise. I'm happy they're being found and disclosed and I'm happy that they've a decent bug bounty program.
That's because it's popular to post news about Apple, not because Apple's platforms are insecure "by default". If you think Apple is the only one that has these issues, you're not paying close attention.
the issue with that would be that it's not an exhaustive list. people would feel wrongly safe because they don't visit those websites while in theory a lot more websites could be infected.
It’s just iOS. But, considering that all browsers have to basically use Safari (or rather WebKit/WebViews) on the backend, I would assume it affects any browser on iOS. With that said, that’s just a guess and I do not know for sure.
Can someone explain to a C/C++ newbie why the iPhone is so vulnerable to overflows? My understanding is that tools exist to check your code and identify overflow-able areas or general unsafe pointer areas. Am I incorrect here?
Also, from a broader point of view - is there any way to perform static code analysis and enumerate all code paths that access sensitive resources? For example, create a graph of functions and search for edges to and from the keychain. If one path ends up in a WebGL content renderer, that’s a vulnerability. I feel like this especially would help you enumerate most exploits and zero-days.
I'm far from good enough at c/c++ to give you a solid answer here, but basically while yes there are tools that can help, you cannot be 100% protected from issues like this.
> is there any way to perform static code analysis and enumerate all code paths that access sensitive resources
This starts to get towards something akin to the halting problem. Not exactly, but you can sort of intuit why this doesn't work in practice. The combinatorial explosion kills you.
I would say that it's also complicated by the fact that it's a design feature for the web browser and various web pages to have access to sensitive information. So the answer to "Is it possible for the web browser to do X?" is going to be "yes" for a wide range of X's.
It isn't just combinatorial explosion. The number of paths is infinite. So you must use widening or have a finite abstract domain for ay abstract interpretation.
Not the iPhone itself but all C and C++ codebases. It's possible to write code in these languages without these bugs, but there's a strong positive correlation between lines of code written in these languages, and this class of bug. Other languages will either insert a check before access (which is overhead) or try to elide it as a compiler optimization.
Current static analyses are imprecise, while dynamic analyses require actual execution which can be difficult.
Modern research is looking to combine the two. Rather than brute force fuzzing (dynamic analysis), static analyze the source to better mutate the input to a few potentially interesting cases.
> It's possible to write code in these languages without these bugs
I would go so far as to say in any non-trivial codebase it's virtually impossible to avoid introducing a bug of this nature. SQLite is probably the codebase that has the highest chance of being safe from this, due to its extremely thorough test suite and amount of fuzzing that's been done, but even that codebase was found to have a significant bug (I forget the details) in one of the optional first-party extensions, as that extension did not have the same rigorous test suite that the SQLite core did.
To be clear, when I say thorough test suite, IIRC SQLite's test suite has 3x as many lines of code as the code being tested. And I think there's some sort of instrumentation to ensure the test suite covers every single code path.
Covering the every single branch of code isn’t enough. One needs to test that every single branch isn’t vulnerable to an overflow attack.
It’s kind of testing every possible valid, invalid and malicious input the program can take in.
Gets even crazier with race conditions and such.
Testing is really hard. And given how many companies skip on testing I am led to believe security is a myth. There’s gonna be someone somewhere with an exploit getting your info.
Yeah, which is why fuzzing is important even with tests covering every code path. And even with that, this is why I simply said that SQLite is probably the codebase that comes the closest, rather than saying it actually is bug-free.
Basically, managing memory is hard, and usually the way you manage the memory depends and interact in the way the OS manage the memory (so not your error but OS or drivers...).
Also, sometimes your design make it difficult to keep track of your memory because you share pointers to different processes and classes and you usually make this interactions to be efficient and fast.
Basically, if you are a beginner, building easy things in C/C++, you can stick to the basic rules so you never fall in this kind of traps, but if you are an expert focusing in optimization (or time sensible applications) sometimes you make assumptions or rulesets so "you can't use this class like this", "you can't never pass a pointer with less than 64 bytes allocated", and after a couple of months and some people and hat changing they end up making mistakes...
All browsers on iOS basically use Safari on the backend since Apple doesn’t allow other browser engines on the App Store. My guess would be that it affects all, but I don’t know for sure.
I once foolishly clicked a link in a text message. Out of curiousity: I knew it was spam.
Should have used a link previewer. It went to a porn site that looked....odd. Like one big static image mimicking a porn site, nothing clickable.
This was a couple years back. Always wondered about it. Does it seem remotely likely it was some kind of exploit that may still be running on my phone. Have upgraded since and am fully updated.
Note: THIS exploit is removed by the patch. Am wondering if this is a reasonable worry in general that would warrant wiping the device and restoring photos, messages etc via icloud sync rather than a backup.
As explained above, this particular exploit only remains in memory until you reboot the device. Unless you visit the site again after the reboot, no trace of it would be left on your phone.
If it was indeed this exploit, they had your data at that point already though. No action will undo that, but changing secrets might help.
> Malware could steal passwords, encrypted messages and contacts
Does this include 1password passwords? As far as I understand 1password encrypts the passwords and they can only be accessed either by supplying the master password or the fingerprint.
The exploit gets full root and full access to the keychain store. And apparently the 1password master password is stored in the keychain when sync is enabled (https://discussions.agilebits.com/discussion/10412/storage-o...). So they had the technical ability to steal at least a few 1password passwords.
But 1password is not in the default list of apps to steal (https://googleprojectzero.blogspot.com/2019/08/implant-teard...), so you'd have to know what commands their server sent to get a definitive answer. Most likely they didn't bother, as it seems more like a surveillance / monitoring operation than for financial gain, but then again attackers are getting more sophisticated all the time.
One of their employees wrote about it here: https://discussions.agilebits.com/discussion/106629/ios-secu.... His response is basically that OS-level 0days aren't in their threat model, so they're continuing their usual bug-fixing routine. And it's true, nothing can really stop a rootkit from sniffing passwords as they're being used, besides winning the anti-rootkit race. Perhaps 1password could have a little more explanation of the insecurity of using Touch ID / Face ID though rather than simply saying it's as secure as possible.
But keychain itself is encrypted . I thought it was stored in secure vault too. Anyways, how does finding a kernel issue, let them subvert a hardware based decryption mechanism, like face-id or thumbprint
I am not able to read this article on my iPhone SE. first the two pop ups (one about cookies and one about how I read 1/3 articles) covered the entire screen. I took a screenshot and sent it to someone. When I went back to safari I was greeted with a full page ad with no way to close it. So I cannot read the article. Sad.
I always suspected this. Years ago, there was a public jailbreak technique that could be initiated merely by visiting a webpage. It always seemed to me that if this technique were found for a later release of iOS and not publicized, it could be used for the deeply nefarious purpose of stealing information.
How did this malware compromise the iPhone in the first place. Did Apple insert a backdoor for the spooks that was discovered by a third party. It wouldn't be the first time as Google is reported to have inserted a government backdoor that was subsequently used by the Chinese.
what could be the reason for Google to avoid publishing the site list? There's something being hidden here..and how could they even discover this? Is not like they did basic cyber research and found the exploits
we render the following service within 48 hours. We render the fastest service of any hack job. With multiple hacking skills and techniques, we provide the best job on any hack job. We specialize on the following below
University grades changing
Twitters hack
email accounts hack
Grade Changes hack
Website crashed hack
server crashed hack
Retrieval of lost file/documents
Erase criminal records hack
Databases hack
Skype hack
Websites hack
Facebook hack
Text message interception hack
Email interception hack
Credit cards hacker, wiping of credit cards, increase of credit cards scores
CONTACT US @ Theredhackergroup@gmail.com or whatsapp:5713189498
105 comments
[ 3.8 ms ] story [ 185 ms ] threadPeople do “deep dives” of exploits all the time, the amazing thing about this particular one is that it gets to the keychain and is via a website.
Aren’t there tools that can analyze existing code and enforce memory safety?
Not perfectly.
> Apple patched the bugs quickly in February 2019 so everyone who has updated their iPhone since then is protected. Rebooting the iPhone wiped the malware but the data had already been taken.
Why in the world did they silently fix the issue and remove the malware? I'm fine with all of this, but shouldn't they disclose to the user "hey, some very sensitive data from your device has been taken. It is passwords, messages, etc." so that users could at least try to mitigate the impact somewhat (contact their contacts, change passwords, maybe change numbers, etc.)?
Please read the original source at https://news.ycombinator.com/item?id=20835223
So if you don’t tell me I need to reboot my iPhone, I won’t.
I can't see how any software provider (ie Microsoft, Linux, Google... ) will say "install this patch to fix this and you may or may not been hacked, good luck"... They just provide the patch.
Consider a lock manufacturer that has a key copy of each client. If someone enters in the building and steals all the keys, clearly the manufacturer should inform all their clients. But, if a vulnerability has been found in a lock model, the manufacturer can tell you about the vulnerability, but definitely they can't tell you if your house has been robbed that way (or if it has been robbed at all).
Anyway, with this story alone and without knowing if you have visited these webpages that allegedly hacked your iPhone (why aren't they listed?) the only thing you can do is renewing passwords in your most critical accounts.
It’s not big news when it happens all the time.
What is big news, that’s gotten lost in all the noise, is that Google (through it’s crawling of the web) has been able to identify that some websites were (are) indiscriminately jailbreaking iPhones for the purposes of stealing user data.
This is the kind of thing that is routine on Windows, is likely to be routine on Android (given how many unpatchable devices are in use) but wasn’t considered to be routine on iOS.
The takeaway from all this is simple: if you’re not fully patched, you’re at significant risk. It doesn’t matter which platform you use.
This is part of the reason CVEs and security bulletins exist. We're being notified about potential issues all the time by many vendors.
But CVEs are intended for specialists. "Users" don't know about CVE.
Because Apple wants to maintain the facade that you can trust them with your data.
It's not bad for the phone, and whether it's bad for the battery depends on the battery technology. In fact previous battery technologies were recommending the occasional full drain!
For lithium-ion batteries the kind used in the iPhone draining to 0% can indeed strain them (though less than you think, as shown by research), but the iPhone doesn't let them go to 0% anyway. It switches off way before that (even if it shows it as 0%). Mind you that regular use cycles (defined by Apple as using 100% of a full charge, even if it's broken down as going from 100% to 80% for five days and recharging) also strains the battery. You cannot not strain it, all current technology batteries degrade over time.
Also note that getting lithium-ion batteries to 100% and keeping them charging can also harm them (although modern devices have mechanisms to prevent that). In general it's advisable to keep going from 80%-20% and back, than to go all the way to charged (or down to 0). Same, one should not store long term fully charged.
But most of this is irrelevant micromanagement unless you plan to keep your phone for years and don't ever consider replacing the battery. Even so, the battery lifespan vendors like Apple give is around 3 years of cycles.
All in all, you can fully drain your lithium-ion iPhone battery as often as the average person does (e.g. just avoid doing it all the time), and you'll see no special degradation. It will run its cycles and will degrade by regular use after a few years even if you never let it drain (and you can trivially replace it with a new one).
Why should we trust your statements over ones like these which seemingly are backed by more data and and explanations of the underlying physics?
[1] https://batteryuniversity.com/learn/article/how_to_prolong_l...
More importantly, that such tracking is marginally useful micromanagement (and, Apple's artificial throttling for degraded batteries aside, has nothing to do with affecting a device's speed. A 90% charged device is not magically faster than a 20% charged one). Apple itself, in their document about battery technology and care ignores the "fully drain" issue completely.
Sometimes I wonder if the windows 10 auto-update fiasco was really about people who rarely recharge; and finally charging their laptop the one time they needed to be prepared, only to get owned by Windows Update at the worst time.
I wish there was a good way to report it, neither apple or twitter seem interested.
If Im just browsing I use the mobile web interface since it's just better anyways.
Seems people are going out of their way to let Apple off the hook for not disclosing to the user a major risk and silently fixing it.
1) the GP quoted the part about rebooting wipes the malware. But that doesn't matter if the info was taken before the user rebooted. So this comment is really off topic.
2) the GP comment is about letting users be aware so they can help mitigate the problem and assess the threat level. For example, users need to change their passwords. If you've ever worked with any government agency their number one concern is not leak of data, but knowing what leaked (obviously they want to minimize that). Knowing what leaked is extremely important. This is what the comment is about. I don't understand how your comment addresses this.
"This is the angriest $1500 I've ever spent on a brand new iPhone, but I will probably do this again next year," says one iPhone user.
Apple is not intentionally removing malware themselves, and AFAIK they don’t have the ability to tell if a device has been compromised.
I’m not yet ready to crucify Apple for not issuing a press release listing sites and services affected. Same with the Google “deep dive” with it’s vague insinuations.
I suspect this is a big international incident like - “China bought hacks from Mossad to target Hong Kong” kind of big. For all we know there are gag orders in place and an ongoing investigation.
I will still use iOS devices too. They are still the most secure consumer available/friendly computing devices available imo. That said, I want to know more.
Well then if you use Linux, it's pretty secure. But most money goes into headless servers.
Do you trust the GNOME project, is it well funded? Or KDE or whatever.
Actually fundamentally. Do you trust the X Server?
More relevant: Do I trust SSH? My browser?
The discussion was on phones, there the issues are mostly core Android's lack of updates from manufacturers (but quite good record of Google releasing patches) vs iOS's closed-source buggy OS.
IDK, security is hard. The easiest solution is to get a nice clay brick and smash whatever phone you have to pieces.
How about nVidia with their 5 security issues: https://www.bleepingcomputer.com/news/security/nvidia-patche...
Checkpoint Endpoint AV that allows escalation to admin because of failing to verifying their DLL files: https://safebreach.com/Post/Check-Point-Endpoint-Security-In...
How about Intel with Spectre issues which are still ongoing? Speaking of Intel, their SGX isn't as secure as it could be: https://www.zdnet.com/article/researchers-hide-malware-in-in...
https://stackoverflow.com/questions/11259152/chrome-ios-is-i...
Also, from a broader point of view - is there any way to perform static code analysis and enumerate all code paths that access sensitive resources? For example, create a graph of functions and search for edges to and from the keychain. If one path ends up in a WebGL content renderer, that’s a vulnerability. I feel like this especially would help you enumerate most exploits and zero-days.
> is there any way to perform static code analysis and enumerate all code paths that access sensitive resources
This starts to get towards something akin to the halting problem. Not exactly, but you can sort of intuit why this doesn't work in practice. The combinatorial explosion kills you.
Current static analyses are imprecise, while dynamic analyses require actual execution which can be difficult.
Modern research is looking to combine the two. Rather than brute force fuzzing (dynamic analysis), static analyze the source to better mutate the input to a few potentially interesting cases.
I would go so far as to say in any non-trivial codebase it's virtually impossible to avoid introducing a bug of this nature. SQLite is probably the codebase that has the highest chance of being safe from this, due to its extremely thorough test suite and amount of fuzzing that's been done, but even that codebase was found to have a significant bug (I forget the details) in one of the optional first-party extensions, as that extension did not have the same rigorous test suite that the SQLite core did.
To be clear, when I say thorough test suite, IIRC SQLite's test suite has 3x as many lines of code as the code being tested. And I think there's some sort of instrumentation to ensure the test suite covers every single code path.
It’s kind of testing every possible valid, invalid and malicious input the program can take in.
Gets even crazier with race conditions and such.
Testing is really hard. And given how many companies skip on testing I am led to believe security is a myth. There’s gonna be someone somewhere with an exploit getting your info.
Actually it has a shocking 662x as many lines of tests as it has code[1].
I agree though, SQLite is an amazing piece of software.
[1]: https://sqlite.org/testing.html
C++? In C++ that means take C, make it better but use the original.
Give me a strongly typed language and check for overflows and the like!
Also, sometimes your design make it difficult to keep track of your memory because you share pointers to different processes and classes and you usually make this interactions to be efficient and fast.
Basically, if you are a beginner, building easy things in C/C++, you can stick to the basic rules so you never fall in this kind of traps, but if you are an expert focusing in optimization (or time sensible applications) sometimes you make assumptions or rulesets so "you can't use this class like this", "you can't never pass a pointer with less than 64 bytes allocated", and after a couple of months and some people and hat changing they end up making mistakes...
This might sound somewhat irrelevant, but are you a native Spanish speaker (or typing on a Spanish keyboard)?
I haven’t seen other browsers mentioned anywhere.
Should have used a link previewer. It went to a porn site that looked....odd. Like one big static image mimicking a porn site, nothing clickable.
This was a couple years back. Always wondered about it. Does it seem remotely likely it was some kind of exploit that may still be running on my phone. Have upgraded since and am fully updated.
Note: THIS exploit is removed by the patch. Am wondering if this is a reasonable worry in general that would warrant wiping the device and restoring photos, messages etc via icloud sync rather than a backup.
If it was indeed this exploit, they had your data at that point already though. No action will undo that, but changing secrets might help.
Does this include 1password passwords? As far as I understand 1password encrypts the passwords and they can only be accessed either by supplying the master password or the fingerprint.
But 1password is not in the default list of apps to steal (https://googleprojectzero.blogspot.com/2019/08/implant-teard...), so you'd have to know what commands their server sent to get a definitive answer. Most likely they didn't bother, as it seems more like a surveillance / monitoring operation than for financial gain, but then again attackers are getting more sophisticated all the time.
It's definitely stored for Touch ID/fingerprint 1password access though (https://support.1password.com/touch-id-security-ios/).
One of their employees wrote about it here: https://discussions.agilebits.com/discussion/106629/ios-secu.... His response is basically that OS-level 0days aren't in their threat model, so they're continuing their usual bug-fixing routine. And it's true, nothing can really stop a rootkit from sniffing passwords as they're being used, besides winning the anti-rootkit race. Perhaps 1password could have a little more explanation of the insecurity of using Touch ID / Face ID though rather than simply saying it's as secure as possible.
And apparently this one works until iOS10 : https://www.theiphonewiki.com/wiki/TotallyNotSpyware
https://support.google.com/mail/forum/AAAAK7un8RUqYupi59QYXM...
https://web.archive.org/web/20190322185231/http://edition.cn...
https://chronicle.security
University grades changing Twitters hack email accounts hack Grade Changes hack Website crashed hack server crashed hack Retrieval of lost file/documents Erase criminal records hack Databases hack Skype hack Websites hack Facebook hack Text message interception hack Email interception hack Credit cards hacker, wiping of credit cards, increase of credit cards scores
CONTACT US @ Theredhackergroup@gmail.com or whatsapp:5713189498