Skip to main content ↑ ↓
Topic: Thoughts on how to work with security issues (Read 3097 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Thoughts on how to work with security issues

Yeah, security...
Once in a while it's necessary to talk about that as well.

I have to admit our current "model" is a little lacking in the area, even though no severe security issues (well, depends on the definition) have been reported privately, all of them were either discovered internally, reported at SMF or disclosed in some way. But it's always possible one surfaces and kicks us in the back.

In out current setup, any vulnerability discovered or reported is discussed in a non-publicly accessible board, and this is mostly fine. But still I see at least two weaknesses:
1) when it's time to commit the changes and test the release, because  these two steps are possible only in a public environment,
2) our parent project and all the siblings that may discuss their own issues internally and release without exchange of information before the disclosure.

The point 1 means any hacker following our repo can have hints of how current ElkArte forums are vulnerable.
The point 2 means that there is a lack of communication between the different projects that usually results in one of the projects release a security update and potentially exposing all the people using projects with related code to the risk of being attacked. The few times I discovered a security vulnerability in ElkArte I seem to remember I reported it to both SMF and Wedge, anyway, I feel a bit of standardization and collaboration between projects would be indeed nice.

Of course this is sub-optimal.
So, what can we do to improve things?
I can think of two ideas:
1) a "security" list, with access granted to a restricted number of people to discuss security related reports,
2) a private repository where develop code involved in security issues.

The first point is rather easy to have, have the various projects share reports to that list would be an advantage for everybody[1].
The second is somehow easy as well, a BitBucket repository (BTW I think there was already one) offers unlimited private repositories. It may be even an idea reach out Github guys, explain the situation and see if they can spare one single private repository for the project[2]

Then there would be just to use the tools.

What do you think?
1 Just to be clear, I'm not saying all the issues have to be reported to a single central mailing list accessible to all the developers of all the SMF-derived projects. What I'm saying is have a list where meaningful reports that are likely to affect more than one can be shared and discussed between representatives of the projects and people with some knowledge of security.↵
2 I know Simple Machines was granted few private repositories at the time, I don't remember the details though.
This to say that Github guys are flexible if necessary.↵
Bugs creator.
Features destroyer.
Template killer.

Re: Thoughts on how to work with security issues

Reply #1 –

Seriously, security issues are tough especially to those who only do simple programming and have less time to spend in this field, like me.

I want to contribute, as I also have a dream (or so called plan) to create a Malaysia national school forum under sch.my domain using ElkArte software, but my time and resources for this are very limited.

So, at this juncture, I am not so sure how to contribute though I may like to participate and help more if I can.

For now, I guess I am agreeable for a list of security issues be drafted and a private repository be created as @emanuele suggested.

Re: Thoughts on how to work with security issues

Reply #2 –

I don't think a private repo is necessary. At some point the fix will be released and at that point everyone will know. If anything would need to change it would just be the speed of the release.

Re: Thoughts on how to work with security issues

Reply #3 –

In theory yes.
At the moment there are very few tests done once the fix is pushed (and this is already kind of sub-optimal by itself, but okay), and in theory we could trigger a release in a few hours. But in practice (in order to balance the various needs), any release can keep security patches in a public repo available to anybody for days if not weeks. Plenty of time for exploiting.

What I was thinking was more: on the public repo you continue develop the micro release like usual, on the private only the security patches are applied. When it's time for the release (let's say few minutes before the packaging), the commits from the private repo are pushed to the live, the release is tagged, the package is created and the announcement is made. The total time of public availability of the bug without patch counted in minutes or hours.

Of course, then people can wait days or years before apply the fix, but at that point it's their fault.

Dunno, maybe I'm over-thinking it. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Thoughts on how to work with security issues

Reply #4 –

I think you're over thinking it. It's not an issue now and has never been an issue as far as I know.

Re: Thoughts on how to work with security issues

Reply #5 –

It has never been an issue for SMF because up until... up to now (because 2.0 development is still happening in a private repository) the development happens in a repository accessible only to the team members, and security patches are "tested" only be beta testers and team members.
It has never been an issue for Elk because... well, nothing too serious arose, but for at least a couple of patches I tried to use that process.

It is anyway an issue for other projects that care about security, e.g:
https://www.mediawiki.org/wiki/Developing_security_patches
Bugs creator.
Features destroyer.
Template killer.
 

Re: Thoughts on how to work with security issues

Reply #6 –

I found the original repository I set up for that 2 years ago and actually used for the very first security issue (HTML tag posting):
https://bitbucket.org/elkartesecurity/elkarte
at the moment it's a private repo only accessible to me, TE and Spuds.

And I just pushed the code I've written to address the current one.

Now we'd need an email address to receive the reports...
Bugs creator.
Features destroyer.
Template killer.