So they're using AES in CTR mode for encryption. They encrypt both key (website + login) and value (password) using the same key (wallet private key) and counter (1). [1] Which means you can just bruteforce popular domain names, xor encryptedPass ^ encryptedKey ^ domainName, and get first bytes of the password (depending on domain name length), just by going through some recent TXs at [2].
I was looking forward to reading this article (it's the second part) to see how the author would bypass aslr but they just disable it (running under gdb) so in the wild their method would not work.
This seems to be a common practice in documenting exploits -- to purposefully leave out details that would make it able to cause actual damage in the wild.
ASLR has been thoroughly broken through cache and memory subsystem timing attacks. It seems reasonable to leave breaking ASLR as an exercise for the reader in order to focus more on the core vulnerabilities being discussed.
> It is worth noting that for the sake of this exploit I assumed the attacker has knowledge of the memory layout of the executed program(3)
This is not the same as saying "this cannot be exploited with ASLR".
Ever since that paper was linked to on Ars everyone thinks ASLR is done for. ASLR was always vulnerable to cache timing attacks. ASLR can not protect you in the case that you can arbitrarily compute on the target machine - this is not new, this has never been the goal of ASLR. That paper was not the first to demonstrate this.
If you can not arbitrarily compute on the target machine ASLR is still completely useful. This is the case for tons of vulnerabilities, like basically anything that isn't a web browser with JS execution privileges.
> If you can not arbitrarily compute data on the target
> machine ASLR is still completely useful
Cache timing and other side channel attacks can be done remotely. RSA implementations have been broken via side channels across ethernet and even via thermal noise.
That said, that ASLR could theoretically be broken remotely hardly implies that ASLR isn't an effective mitigation.[1] If you can quantify the rate of leakage across the channel you could, for example, throttle requests to make an attack impractical. Just be careful about underestimating the rate of bit leakage, or forget that a few leaked bits can make practical a brute-force trial+error attack.
This is why, arguably, the new best practice in writing service daemons (see recent OpenBSD work) is to fork+exec when restarting a service, even when restarting it statefully; as opposed to just resetting internal process state. Also, daemons and daemon slaves should be periodically restarted automatically.
This can be difficult to do, especially if you want to avoid dropping existing, long-lived connections. But when writing new software it's not too bad, especially if you farm out sensitive work (e.g. key signing, complex object parsing) to subprocesses that can be spawned and reaped independently and at a faster rate.
[1] We shouldn't discount the distinction between targeted and untargeted attacks. Currently untargeted attacks don't typically rely on breaking ASLR via timing attacks, and even when they do we can expect that the _cost_ of mass scale timing attacks to be significantly greater. Basically, there's no reason to believe ASLR to be a completely useless mitigation against remote exploits; quite the contrary. Useless for local exploits? Maybe, especially considering that Linux and Windows kernels are so riddled with exploits.
tl;dr: a CVSS 7.8 Windows vulnerability in the SMB service can allow an attacker to DoS any machine with the filesharing service exposed; the possibility of RCE seems to have been discarded; exploits are freely available online. This article complains that Microsoft's communication is lacking details and transparency in times of war
Alternative client/UI: check out PleXBMC, you can use any theme you like. That said, plex media player will provide a superior experience as it's using mpv.
irccloud keeps going down every time freenode netsplits. It got so bad lately I actually canceled my subscription and instead set up weechat+glowing bear, which is not as polished, but it works fairly well on both desktop and mobile. (And cheaper)
It's also free software and easy to set up so I encourage everybody to check it out.
Does it still work if you've got WeeChat customised or does it need to be vanilla? I'd like to keep using it from a shell while on a decent machine, but would absolutely not mind the option to connect from mobile clients.
Dev here. It's completely independent of your config. Indeed many things carry over to Glowing Bear automatically, such as scripts that modify the lines (colorize_nicks.py) or create new text buffers (like highmon or grep.py), filters, triggers, etc.
Did check it out. Absolutely amazing project and if anyone still reads through this chat, absolutely what a modern IRC experience should be like in my view. Effortlessly does a lot of the things people on here like about Slack.
I like WeeChat as a client, it's fast and lean and works inside the tmux session that pretty governs my digital life both private and professionally. Alas, it's not always accessible. Getting Putty to reliably work with tmuxed ncurses apps is a nightmare for example, imho.
Glowing Bear solves this brilliantly. It looks great, you get features like inline display of media and is easily secured with certificates from Let's Encrypt.
Thank you, devs. This'll make my "newly discovered FOSS projects of the year" list for sure.
Vector (+Matrix) is kinda like self-hosted slack/discord with proper history sync across all your devices, file uploads, nice UI, etc.
It's really good. I recommended it to 7 people and every single one liked it, even got 5 of them to set up their own federated homeservers. We're thinking about moving a ~60-people skype group there as well.
Only issue I had is Synapse hogging the CPU and getting laggy with a large room (#matrix:matrix.org with its 4 thousand members). I'm using scaleway's 3 EUR/month Starter VC1S server for Synapse though. Hopefully it will get even better with time.
Or you could just use IRC with quassel + quassel-webserver, and get basically all of the same, but with an actual open protocol. Which actually has support.
Actually matrix - the protocol upon which vector and now riot depend - is an open protocol; reference here: http://matrix.org/docs/spec/
And then of course, there are the matrix bridges to IRC, etc. Admittedly although i have been using vector clients AND have installed my own personal synapse server, i have no experience using/supporting the various matrix bridges, so can't speak to their quality.
That being said, if you've ever been curious about re-doing some aspects of IRC for the better, you might want to take a look at matrix (the protocol), and suggest improvements; we all stand to benefit from your (and the community's) suggestions.
So who's working on federation and single identity across IRC networks? Who's working on a protocol which would let me ask other users for their chat logs from before I joined a channel? Who's working on WebRTC signalling over IRC? When will bouncers be built into IRC servers so I don't have to run my own? When will IRC have a standardised HTTP protocol by which I can run whatever webclient, mobile client, or otherwise that I want? When will it support proprietary push services to keep mobile battery life up?
IRC has had 28 years to do any one of these things.
It’s not just about developer time, it’s also about the users.
The amount of users willing to use an open source chat system is limited.
If we want to profit from the same network effects that proprietary chat systems profit from, we need to get everyone into one system, which also scales to extreme scales, and, yes, allows content censoring on some level – but also allows anyone to open their own federated server with different censoring policies.
Adding more standards doesn’t help, unless they federate both ways.
(Although Matrix is the least problematic example there, Signal is far worse in those regards)
> Adding more standards doesn’t help, unless they federate both ways.
> (Although Matrix is the least problematic example there, Signal is far worse in those regards)
Not everyone in open source is out here to dethrone proprietary systems (although many of us have "enemies", my personal one ATM is Oracle, although with a smile, -I wouldn't sabotage them even if I could get away with it but I love to tell people about alternatives)
Some are just experimenting, some are building reputation, some are just out here to make the world a better place for everyone etc.
Telling people who produce nice useful stuff to "stop the project, burn the code" is, IMO, rude and harmful.
Edit: Let me add, - thanks a whole lot for working on opensource and on irc specifically. Many of us here love IRC and the reason why I downvoted one of your earlier comments is because we don't think anyone should be allowed to tell people what open source projects they should or should not start or contribute to.
The user I replied to asked me what I’d suggest to fix with Matrix, or change with it.
So I replied honestly.
I knew most wouldn’t like the answer, but it’s still what I’d do.
I also didn’t suggest to actually do it – just that that would be what I’d do, if it was my responsibility.
> some are just out here to make the world a better place for everyone etc.
and
> Not everyone in open source is out here to dethrone proprietary systems
Are the same, though.
It’s just that if we want to compete with products that have multiple-billion-dollar marketing budgets, have thousands of paid engineers working on perfectly planned timelines, etc, we really need to coordinate.
The "let’s go and everyone build their own" is good for hobby projects, but as soon as it comes to building something for users to actually use, you need quality control, coordinated branding and marketing, you need focus of development, you need people doing QA and support.
Also take a look at IRCCloud or Quassel or Weechat+GlowingBear to see what can be possible with IRC already today, if you use a modern bouncer. (Part of the work of IRCv3 is integrating that functionality again).
Occasionally you need to re-baseline or you risk getting mired fighting backwards compatibility and the limitations of the original design. Just like Git "rewrote" Subversion. Or clang "rewrote" gcc. Or PNG "rewrote" GIF.
It's incredibly shortsighted to assume that attempts to create new projects that overlap with old ones are are splitting dev effort and harm overall progress.
Matrix is not trying to split any community. If it were, it wouldn't have bridges to IRC, Slack, or any other chat system.
I'd like to see Freenode integrate a seamless bouncer. I suspect I won't in the next few years. Right now, Matrix provides one. Fancy that. (Also, I'm chatting across four different Matrix servers, with people in those rooms from many more, and have only ever had to manually connect to one server (my own) and have only had to create one account. IRC isn't working on fixing that.)
Yandex offers unlimited users (up to 1000, then you have to contact them and I guess they will allow more) and claims unlimited storage, zoho free tier is 25 users and 5 GB storage/user.
Any idea if they support email 'distribution lists' or similar? I want something like [email protected] > delivered to list of users with a mix of email addresses at other domains. Gandi.net does this now (they call it a forwarding only address) but their included mailbox size is 1GB. I've got a non-profit domain that needs more email storage.
I tried Zoho last year after hearing multiple recommendations and it was nothing but problems with spam coming in and my outbound emails being incorrectly marked as spam. I even had SPF + DKIM tested and working from the start! Not sure I would try them again after that experience.
Your first link appears to require the installation of an app on the phone (after installing a dev certificate). The app, running arbitrary native code, performs the actual jailbreak (most likely using a chain of kernel exploits).
The devs seem to have gotten around the App Store by using an approach like TestFlight, which allows apps to be deployed for development and wider testing purposes without going through the App Store.
I know one of the original iPhone and iPod Touch jailbreaks worked that way. I just went to a website and it automatically rooted and installed the homebrew app for me.
None of these exploits have anything to do with accessing TCP services using a browser. The only exploit there having anything to do with Safari, CVE-2016-4657, is a WebKit memory corruption (per your [1]: "The stage1 employs a previously undocumented memory corruption vulnerability in WebKit to execute this code within the context of the Safari browser (CVE-2016-4657).").
