What is MDG's position on Sikka?

core
24

I just reviewed your sikka package and I’m genuinely impressed by the clever architecture and hacks you used so that’s it just work™ by adding the package.

The code misses a few comments to explain the author intentions, and because of that I wrongly thought I found a security leak (by re-using the human-token) :slight_smile: Now that I understand how it works, I believe this package has the quality level being requested in this thread regarding the “core-feature” of preventing DDOS attacks.

PS: I’m not sure if this is intentional but you never check if Sikka._rateExceeds("perSession"). Since you already do it for perHuman and perIp I don’t think this is dangerous but I just wanted to ask you if it is an omission.

2 Likes
25

Which brings back the original question. Is it the bare minimum protection a prod app should have? If it is, then why would you want Meteor sites to go unprotected?

Imagine if there was a community package to do html encoding and MDG said “Great, one thing less for us to worry about and spend resources maintaining. From now on if Meteor sites want the bare minimum protection against injections they should just add package X.”

As ridiculous as that scenario may seem, if Meteor provided something like Sikka in core, people would find it ridiculous to get rid of such package because there was a community version of it.

26

Thanks max.

PerSession check was left alone intentionally. May be I will remove it altogether.

27

This is a great thread, and I’m glad to have you on board, @manuel. I feel like I’ve been focused on some of the larger issues like making it at least script-kiddie proof, worrying about the licenses that come with each package (so you don’t accidentally introduce a copy-left license), etc.

In my opinion, Meteor is just beginning to climb that hill, and it’s 100% valid to raise the issue and get a resolution.

I will say that in the past when an issue was discovered, MDG was appropriately quiet about it, worked feverishly in the background to fix it, and then released a backwards-compatible patch that fixed it. Only then did they take a public stance - which is a pretty common policy in the world of security.

Having met the MDG and Matt, my vote is on their ability to get the job done. I have no concrete info, but my bet is that they will indeed pull this into core. If it is an architectural vulnerability of some kind, intrinsic to Meteor, their history is to patch that and quick. Their goal is adoption, and this would be seen as a pretty major roadblock to that.

And my money is where my mouth is. We are about to launch our second seven-digit site on Meteor, so if I’m wrong, I’ll pay the price. Feel free to PM me if you want to chat in more detail.

I think in the end, it may or may not be as serious as it sounds (lacking clarity from MDG), but I would argue that the other point being made in this thread is the more important one. If anyone can trot out a modern, scalable networking stack without vulnerabilities, I’ll eat my hat. There are problems everywhere - if their requirement is “no vulnerabilities”, then I imagine the suits would be ROFL’ing regardless. I think your real point is “Wait - this is pretty hacky, and is going to sound weird if I have to put some random dude’s plugin into the system just to patch glaring holes.” Again, I trust that in a very short amount of time, we will see that MDG stepped up and gives you a much better story.

I hope that when that happens, you’ll turn it around and use it as an example of why the suits SHOULD be excited about using Meteor. The fact that there’s a community of checks and balances, people actively finding and patching issues, which then get rolled into core, is a pretty impressive thing - it should give you a sense of confidence, not one of mistrust.

My $0.04!

PS - I, too, am very interested to hear @debergalis or MDG comment.

3 Likes
28

I’d just like to add one more point if I may to this thread. Now in my third decade in Silicon Valley, one thing I’ve learned repeatedly is that a leading individual authority is often more reliable, predictable, and responsible than a corporation is. This may surprise many who think “an established firm” is somehow a stable foundation one can build upon. But every morning large corporations blink and shed entire divisions, or roll over in their sleep and destroy entire industries. And small ones get bought & repurposed or have their lights turned off by impatient investors.

Meanwhile the individual who has found their niche and life-purpose in a given tool will continue to be devoted to the vision long after the lights are out. That’s where we developed the phrase “you can pry this tool from my cold, dead fingers.” I know this so well because 25 years ago I was the “Arunoda” of an obscure programming language only fellow fossils would remember. And when their investors balked it was one of the most trying times in my life.

I am very positive on the subject of Meteor regardless. If they can get ~$500M in valuation built atop their tools they will be able to remain independent and prosper no matter what. It’s not so far away, and we’re shaking out the rocks.

7 Likes
29

Honestly, the security issue has been in the back of my mind but if it wasn’t for the overwhelming awesomeness of the rest of Meteor (which does have some security measures baked in already) I probably wouldn’t be working with it full time now.

There is a card that was posted on the Trello road map on security, but sadly on a list pretty far to the right with little attention. But what can you do. MDG has like probably single-digit developers with tons of stuff (awesome stuff) to work on and they’ve come a long way.

Thankfully, I’m glad Arunoda created that package.

I do have to mention that there are security measures that can be enforced on the server side (not nodejs but on OS level) and third party services like Cloudflare. However, if you want websocket support on Cloudflare you’d have to pay for an enterprise plan, otherwise you’d have to serve up your Meteor app with DISABLE_WEBSOCKETS=1. Arunoda has an article on it, look it up.

2 Likes
30

We’ve discussed adding configurable rate-limits to livedata for rogue DDP clients issuing method calls, subscriptions, and other DDP commands. I think it’s a sensible direction. Ideally you do it in an extensible way, so that (for example) the use of a CAPTCHA to override the rate limit can live in Atmosphere as one of many alternative extensions to the basic functionality.

What’s more interesting to me: if you pull on this thread you find a strong argument for DDP.

While the Rails community has an analogous solution to (a portion of) Sikka in rack-throttle, deployments with the most at stake tend to address DOS and client rate-limiting in HTTP-land: with software like nginx and varnish, and services like Cloudflare. For many reasons: these tools can be written in languages more appropriate for the task than Ruby, they can be used consistently across a whole organization running multiple apps written in diverse technologies, they keep the rogue activity far away from sensitive application code, and so on. These solutions are possible in environments based on HTTP. But they don’t work for modern apps that hold open a websocket.

And that’s one of the reasons we are so keen on DDP. It paves the way for an analogous ecosystem of flexible infrastructure that can solve problems like this in a consistent and principled way at the protocol layer.

6 Likes
31

@debergalis it is great to hear that this is under your radar.

Is it possible that you

  1. Share a broad timeframe about when you’d release at least a candidate version of your take on ddp security?

  2. Start a hackpad now so that we all become more aware of what we are facing right now and authors of rate limiting packages can craft their immediate solutions accordingly

Regarding (2), I know discussing security and current open attack vectors out in the wild may not be the best idea so at least you can perhaps do an invite-only discussion with those already invested in the idea.

In the meantime, I’d like to let everyone know that the currently available solutions are (at least) the following:

We can perhaps create a baseline requirements list from what these guys have accomplished so far.

3 Likes
32

I don’t think is smart to rely only on meteor to handle security.

Come on guys, people invested billions on making linux a secure server environment, why reinvent the wheel?

I welcome Sikka, and I think @arunoda is a pillar of this community, but I also think that he missed 2 points in his blog post:

  1. What about CPU consumption? the first thing that came to my mind is that if Sikka can block a DoS, it will worsen the situation in a DDoS scenario, where the additional CPU load will bring the server to his knees.

  2. I think @arunoda is a bit exaggerating the risk, as any security concerned developer should do.

Since everything can be reverse proxied via nginx, and since meteor is essentially node.js on steroids, we can use a shitload of solutions already invented, built and perfectioned for us. Guys have you idea about how many research papers are out there on nginx security?

And I also think that the MDG will sooner or later come out with a commercial version of meteor, which will probably include some security hardening services. So @manuel if your company is really going to invest this much, you will have no problem in hiring a security expert, like me, which will drive you to the same conclusions.

Don’t worry, if Meteor is a good choice, DDoS aside, then it’s a good choice also with DDoS taken in account for.

Btw Dos and DDoS are the easy problem to solve. They are like a brute force attack, which use very little intelligence. My shop sell a DDoS hardened (40+ gigabit/sec) cloud solution for around 1-2000$ a month. Which are petty pennies for companies with such problems.

The real threat which will force you to stay always en garde, especially if you handle security sensitive data, are exploits. Very little testing is done on security. Start here, and take notice that DDoS is not mentioned once:

https://www.owasp.org/index.php/Top_10_2013-Top_10

Sikka, like other application layer exploit mitigation techniques, in my very humble opinion, are a very good backup defence layer. Anyhow real threat mitigation should be done at the transport and internet layer first, especially because this way you can build an abstract solution (think snort IDS) that will work independently from the poor code that your developers will write.

2 Likes
33

@muaddib sadly, you are mistaken. We are not talking about dos or ddos in its general sense here.

Meteor is not nodejs on steroids and it does not rely on a request/response model where http layer dos/ddos prevention techniques are typically a dime a dozen.

For normal d/dos prevenion, meteor servers or the nginx etc proxies that they are behind are just the same as any other internet facing tcp/ip based service.

But the problem we are discussing here is completely different and two-fold:

  • Websockets works over a single connection! So flooding meteor server resources over that and protection againsta that is a different story.

  • DDP is a new protocol which carries a whole new family of messages previously unknown, therefore without any standard security implementation. (For example, there is not a single security solution you can buy out there that will limit an evil client’s ability to subscribe to a heavy publication 1000 times in a row.)

Regarding OWASP’s outline, you are mistaken again because application level security has been a heavy concern for both MDG and the community. With that in mind, MDG has gotten Emily Stark on board almost two years ago. She is a top talen security expert and has already identified and solved problems in meteor core. She has also identified and helped solve native mongodb security holes.

And that checklist you provide on that link, you can be very glad to know that they are all solved within meteor except for those that are at the developer discression to program/configure correctly.

1 Like
34

sorry @serkandurusoy, I think this is just a misunderstanding.

In his original post @arunoda show a websocket flooding attack and refer to it explicitly as DoS. In my post I did the same, by referring to websocket/DDP flooding attacks as D/DoS.

DDP is built on top of websocket, and WS can be proxied via nginx. Using this scenario gives you a very efficient C/C++ API for filtering incoming connections on level 4. If you want to dive deeper with layer 2/3, iptables, quagga and other commercial software have plenty of configurations for websocket, which work with DDP too.

I hope this clarify our misunderstanding :smile:

About your statement on application level security being solved, well, simply I’m never going to believe it. It’s like saying hunger has been defeated. The more you say it, the less I believe it.

Even the meteor core had plenty of security exploit, all rapidly fixed. I’m scared to think about all the non-core packages and production code.

35

@muaddib I created another topic over at Are already available network security solutions sufficient for meteor apps? so we don’t hijack this one.

I’d like to hear more from your point of view over there.

Thanks

1 Like
36

Is Emily Stark still on board? I haven’t seen her on Meteor’s Github in a while and I noticed she’s not on this list: https://github.com/orgs/meteor/people

5 Likes
37

She’s now apparently at Google working on Chrome security.

3 Likes
38

You can script all type of sites. Not just Meteor ones.

41

I will just leave this link here: http://info.meteor.com/blog/rate-limiting-in-meteor-core

1 Like
42

Regardless of meteor publishing its own core rate limiting api and that this indeed affects a site or not, you should just be more responsible about publicly sharing any exploit you think you have found. As a community, the best course of action would be to report these to MDG, and then perhaps inform the community that you can exploit meteor apps, but would not disclose specifics.

2 Likes
43

I think this is indeed a course of action that should be done like asked by MDG. I agree that the poster should be more responsible in sharing such code in this way.

If you’ve found a bug in Meteor or have a technical proposal, read our contributing guidelines and file an issue. If the issue contains sensitive information or raises a security concern, email security@meteor.com instead, which will page the security team.

However, I do believe that since the origin of this thread started in March, where a workaround is proposed (Sikka) and it is three months later, such exploits are good to be in full disclosure. Especially when the code required is small and executable without the requirement of having real in-depth knowledge of the Meteor platform and can have effective DoS results. This issue will certainly be overcome in 1.2, according to this blog posting on the Meteor website.

Security is a very important aspect for any web framework. Hence I believe there should be a security guide, as there are various hazards. These hazards do not make Meteor an easy exploitable platform - any web framework goes through this never ending process.

Shouldn’t the forum have a category security?

1 Like
44

However, I do believe that since the origin of this thread started in March, where a workaround is proposed (Sikka) and it is three months later, such exploits are good to be in full disclosure.

I agree that the nature of the exploit and ways to mitigate it should be disclosed. However, the specifics, namely, a piece of code that may reproduce the effect has not place in a public community forum. My reasoning is, this form is for the community, by the community, and there always will be outsiders, such as script kiddies, who will happily try out those exploits without taking a moment to consider the consequences on actual businesses and actual people.

Shouldn’t the forum have a category security?

+1 for this, although a very tough topic to manage and moderate, it sounds nice to have a dedicated category.

1 Like
45

+1 for this, although a very tough topic to manage and moderate, it sounds nice to have a dedicated category.

Rather would like to be noticed here, than to accidentally finding security topics there. I am not sure if the forum guidelines cover posting exploitation code.