Buffer overflows will be an issue as long as code is written in languages that allow memory mismanagement. C, C++ and even Fortran are still here and aren't going away any time soon so this isn't going to change anytime in the near future.
Manual memory management feels like how early automobiles allowed you to adjust the fuel/air mixture by turning a knob: Why are you making me deal with this?
There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows. How years and many units of significant digits of precision do we need on the concept that human are fucking terrible at managing their own memory.
Yes [insert argument about garbage collection stalls] and yes [insert argument about guaranteed response times], but for the vast majority of programming projects those simply don't apply.
The fact that is 2019 and we are still dealing with this is so depressing.
"There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows.": could you point me to this/provide more information?
It's sometimes said that they discovered or anticipated a lot of things that would preoccupy us over the next decades. I was personally familiar with them because David Wheeler mentioned that they anticipated the "trusting trust" issue with a compromised compiler.
Some of their terminology is different from current terminology, but there is, for example, a discussion of tampering with the stack in order to alter variables or control flow. I'm not sure whether the buffer overflow mechanism is discussed because the part that I think I understand is a different means of stack manipulation, specific to this environment.
The reason these languages are still popular is because they're still the fastest and consume less memory.
A better question is why doesn't x86_64 have hardware bounds checking by now? We can already fault at the page boundary, it seems like a minor improvement to have an instruction for malloc/sbrk to create new dynamically sized pages that fault the same way.
Doing so would also be backwards compatible with all the existing software that relies on malloc.
“Huge/Large/Super pages” (https://wiki.debian.org/Hugepages) exist because the typical 4kB pages have too much overhead in programs that allocate lots of memory.
So, sizing pages down to malloc-sized blocks will impact performance, even ignoring the fact that, to have true bounds checking, pointers will have to carry size information, making them larger (64-bit pointers have quite a few unused bits on typical systems, so it may be possible to hide that somewhat.
Also, if you truly want to do bounds-checking, you will have to create a ‘page’ for every element of every array (either up front or on demand), and, if such elements have structure, for each part of the structure.
Huge pages mainly exist to alleviate TLB pressure and page fault latency. But that performance penalty is tiny compared to the alternative of in-program bounds checking that we currently use.
Similarly, pointers don't necessarily need to be changed and your array problem isn't valid. Cachelines could be marked with canaries that fault on read/write, similar to how the NX bit currently works.
The NX bit is actually a good example of a hardware security-performance trade off that nearly everyone agrees on. Now 20 years later, we can afford to mark several more bits at some cache offset for a hardware bounds field.
Programming in a language other than C++ sometimes feels like putting training wheels on a Ducati and driving 30mph down the freeway. And if you know what you are doing in modern C++, the memory is much easier to deal with. You can do anything and more modern iterations of the language add some nice updates to the syntax sugar. It is rather dense to get your head around it, but once you do it is like writing poetry. I like the idea of just making the hardware safer, is there any downside to that?
This is broadly how Intel memory segments were supposed to work.
The 8086 did not check bounds, so nobody bothered using them, and when the 80286 came out that could check, everybody disabled that feature and used it as a faster 8086.
Probably too many key programs played too many tricks assuming a flat memory model that this was never going to fly.
The root issue isn't code but the availability of ram. So long as it is a precious shared resource, overflows are a threat. In the near future the separation between ram and storage may become moot. We could then erect much stronger walls between processes, even separating them physically, so that such cross-talk is much less likely.
Can you elaborate? Putting aside rowhammer-like vulnerabilities [that don't fall under "overflows" anyway], how is shared physical memory under a modern protected virtual memory scheme leading to overflows? Additionally, the word "buffer overflow" usually refers to overflows that take place in the same process.
The process crosstalk (information disclosure, heap grooming, heap manipulation) that takes place to trigger the overflow, wouldn't be affected in the least by physical separation. In many cases (exploitation over the network), you have exactly that.
I would say that this depends on your perspective. While Trump likes to talk bad about the EU, NATO and FVEY members, our military, intelligence and economic cooperation is still VERY strong. And I see no indication of this changing, outside of the rhetoric coming out of the White House. Our Allies know that pulling out of Syria via Twitter was not a decision that came from the Pentagon.
Quite, Any browser that doesn't use chromium is the correct choice. Monopolies are bad, and it's hilarious that people are celebrating one of the demise of one most destructive monopolies of the computing age with "just use $new_monpololistic_product, it will be different this time"
A lot of the same people decrying the Chrome monopoly never the less push for more and more bloat in the web standard, thus helping to enforce that monopoly by ensuring that hardly anyone has the resources to make a reasonable competitor.
More proprietary than "basically Google just tells everyone how it's going to be"? Maybe. It'd be hard to make it worse though. What people seem to really want out of the web is a VM platform and a document layout engine, so why not design a new VM that is intended first and foremost to be an efficient application platform, and then make one of those applications an open source document layout engine? You don't have to be married to HTTP and all its woes either. You could even port a current "legacy" browser to it. And if that document layout engine is found to be lacking, we can make a new one without breaking everything because its just another application on the VM.
Hell, you could compile the VM with an HTML5/JS target and get forward compatibility too.
A worse standard is unlikely to win people over. Even a better standard is unlikely to win.
Take HTML, JavaScript, and CSS, remove 90% of the cruft. Now, include what people want like a much better table element that by default can handle Adaptive screen sizes etc etc.
Chromium and Firefox are open source so you can probably get support in them by writing the code yourself. But, good luck gaining traction.
At least Webkit/Blink are open source and have multiple implementations. With that in mind, how do we distinguish between a "monoculture" and a "standard"?
I feel the same instinctive feeling that we're just going back to the IE days, but is it possible that having all browsers align on a single rendering engine could prove to be helpful rather than harmful?
About 5 years ago we had 4 browsers with significant share - IE, Chrome, Firefox, Safari. Even 10 years ago Firefox had a decent impact over over 25% and IE was being brought down into the "managable" area of 50%ish.
uMatrix is the best at blocking all sorts of content. One can selectively enable and save preferences per website, and that is helpful since uMatrix tends to break websites using CDNs.
What are the benefits of using Slack over Discord? I know Slack has been around longer, looks more professional and has more tie-ins with work flow management tools but those seem like small advantages compared to how feature rich Discord is. Just genuinely curious as I prefer Discord for communicating with my coworkers about non-sensitive information but it doesn't seem to get any love outside of video game and internet communities.
One thing I can't help but notice is that Discord and its API are pretty unreliable. My bot and users regularly encounter unavailability errors. But mainly my bot.
It makes me wish I could pay a monthly fee to get better service, but in reality I'm sharing the same freely-distributed resources as any spammy Discord server. For example, I've been in Discord servers incessantly spammed by its users counting to the number 1,000,000, messages scrolling by like access logs during a DDoS. And I'm sitting there chuckling, "my server is in the same bucket as these people?"
At least Slack lets you pay them for an uptime SLA. I don't think I'd use Discord for a serious venture.
That said, surely your niche plays a large role in which one you pick. I'm somewhat in the gaming niche and Discord was a no-brainer. Gamers/teens are already on a dozen other Discord servers. Meanwhile, all of the Slack groups I'm a part of are professional.
> At least Slack lets you pay them for an uptime SLA.
The paid SLA is 99.99%, which is 1hr/yr downtime, but they've definitely missed that on our instance at least. The only thing I can really say that Discord is worse at is that discord has had a couple of total login server failures, but an individual server blipping out for an hour or three seems about equally common on both in my experience.
I am not a fan of either Slack or Discord, but I would guess it is the feature requests that companies have made to Slack around it's API's, data retention policies, access controls, chat logging and monitoring and such that make people lean towards it. Discord could probably implement the same features if they wished to go that direction.
The tie-ins with work flow management tools I get (even though most of this can be set up in Discord as well) but I think the look and tenure of the application is not really that big of a deal. If you want professional looking from a company that has been around forever then pick Microsoft Teams, otherwise pick the best one. And I have a hard time seeing Slack as better than Discord.
Just because you don't care how something looks doesn't mean that's true for everyone.
Fashion and style matter to lots of people. If 2 things are roughly equivalent, the one that's cool and looks neat is going to be the one chosen by the people who do care about those things.
Discord isn't really a Slack competing product as much as it's a Teamspeak and Mumble competing product... or at least at the start.
Initially it was just easy to use VOIP with rich text chat channels. Now they've added in video calls and a video game store meaning they're more gunning for Steam and even less for Slack.
I do not see them as being Slack competing. They're too casually focused to be a threat in an enterprise environment.
Default Windows 10 comes with preinstalled video games, much less a store. Discord already has subscriptions, at some point I see them selling a version with enterprise features.
I wouldn't say they compete directly as one is obviously targeted at corporate and the other is targeted at gamers. But they are extremely similar and even the UI, while themed completely different, is extremely similar.
Discord has a worse TOS that implies spying on you and has large Chinese investors. That combined with less certification means it is hard to use Discord in an enterprise environment.
Discord search at least on mobile is completely unusable for anything serious - you can click a result to jump to that point in the chat, but you can't scroll from there - it just shows a few messages before and after. Compare to Slack which can jump to any point in the chat and scroll as much as you need from there.
Every time I load Discord I feel like it takes pains to remind me that it is not a safe space for me. It is a safe space for Gamerz, who have a marked tendency to behave like unsupervised teenage boys.
Slack has built a business model off commodity tech that was around for decades. It has happy customers who continue to spend money with them and a plan to continue growing their revenue with more happy customers.
Personally I just see it as a refresh of yammer or a business focused discord but at the end of the day someone in procurement is signing checks for Slack.
I wouldn't say that at all. NYC is definitely large for tech on the East Coast but so is Boston in tech R&D, DC for government related tech companies, and Research Triangle in NC and Austin TX (if this counts as East Coast) are both hotbeds for tech startups. There really is no Bay Area equivalent on the East Coast.
Wouldn't even take that long. I could throw together a flashy "antivirus" that looks really good and does nothing more than a simple file signature lookup in a month. I could probably also get some sales of it to small companies that don't know any better. But to be ground breaking in the cyber security world and build something that is the foundation of a new company is just not feasible in 3 years without massive help from VCs, which isn't going to happen without a PoC or connections.
