vexim / vexim2

Virtual Exim 2
Other
70 stars 47 forks source link

Trying to get in touch regarding a security issue #272

Closed JamieSlome closed 2 years ago

JamieSlome commented 3 years ago

Hey there!

I'd like to report a security issue but cannot find contact instructions on your repository.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

kaluang commented 2 years ago

Hey, following up on your question. I guess nobody got in touch with you and nothing has been done about this? Are we talking about a critical security issue that needs an urgent fixing?

runout-at commented 2 years ago

Hi!

Actually I did contact Jamie PM but as I'm not an owner or contact for this repo he can't give me further information.

It would be interesting if the bug is in the exim config or in the php code.

There are open PRs for a long time now and nobody looks into it. Even I have done a reimplementation of the web-gui [0] but never got any comments on it. I'm feeling like the only person using vexim2...

[0] https://gitlab.com/runout/veximpy/

kaluang commented 2 years ago

You are definitely not the only one using vexim2, although not much has happened in this repo for a while unfortunately. Does anyone know who the owner is or who has write access to it?

JamieSlome commented 2 years ago

I do not believe we have received any communication from the maintainers on this.

rimas-kudelis commented 2 years ago

Hi! The repo is owned by the vexim organization, and I'm the co-owner of this organization (together with @avleen).

In addition, @Udera, @gldickens3 and @corux have commit access.

The thing is, I myself am only using Vexim to host like 5 mailboxes or so, and I have my admin interface secured behind HTTP authentication.

Vexim just isn't high on my list of priorities at the moment, and I guess same applies to other committers. But sure, you can send the info to me, or, preferrably, propose a PR here, and it will be reviewed.

Regarding @runout-at's rewritten interface, Python is not a subject I know well, so I just don't feel like I have much to say about it. Plus, I admit, I probably took too much offence from the "I'm rewriting it in Python because PHP is insecure" comment which preceded the rewrite. :grin:

Either way, if @runout-at would like to push his repo under the 'Vexim' umbrella, I'll gladly add him as a committer to the GitHub organization.

I roughly see Vexim as three distinct components: 1) a database schema, 2) a set of configuration instructions/snippets for different mail server implementations, and 3) an admin interface to manage the schema. But these components are very loosely coupled in my head. There's no need to tie the schema to just one specific admin interface. There could be many – in PHP, Python, Go, Ruby, Perl, whatever, so that anyone could use whatever they see fit.

avleen commented 2 years ago

I missed the original issue, my apologies for that.

Truth be told Vexim was a project I did for fun almost 15 years ago when I had no idea how to write code :) It's done a reasonable job in that time but at this point I'm confident it's riddled with all kinds of security holes such as SQL injection and other nasty things.

I can't stress this enough: The project was written when I had zero idea what I was doing other than writing a utility that several of us found useful. But at this point I cannot honestly stand over the code and claim that it is "good" or "safe". 15 years is a really really long time :-)

If anyone is still using vexim in any meaningful way other than to get ideas on how email virtual hosting could be done, please migrate away to another solution immediately. Make it a top priority.

For my part I will update the top of the README now to make this explicit.

I'm happy to accept patches for the code if anyone would like to make them, but otherwise I don't have any time myself to contribute to the project.

avleen commented 2 years ago

And now that I've said that I see there are currently 15 PRs pending. I'll try to find a few minutes to glance at them and accept them, but the overall message still stands: unless someone would like to put in a reasonable amount of effort to check for and fix security holes, you should really consider moving to a different, more modern, and more safe solution.

rimas-kudelis commented 2 years ago

Actually, first commits in this repo date back to 2003, so the code is almost 20 years old by now. By all standards, it's ancient.

But I tend to disagree that this project as a whole is outright riddled with holes or that it's broken beyond salvation. Of course I'm curious what the security issue discovered by Jamie is, but my guess is it will be something like an XSS/CSRF attack, which would likely be quite easy to solve.

I tend to think that our whole admin tool could be rewritten relatively easily in about a weekend using a modern framework, One rewrite was already mentioned in this discussion.

JamieSlome commented 2 years ago

Hi all 👋

Just to pitch in from our side, we have these two reports:

https://huntr.dev/bounties/182b966f-0ea0-4ca2-a78f-5719a2dc2c12/ https://huntr.dev/bounties/675db71a-c3d5-4526-b2ad-4a7dbf9ab9da/

They are currently private and only visible to maintainers with repository write permissions. Let me know if anyone has any questions or issues! ❤️

rimas-kudelis commented 2 years ago

Thanks Jamie! I've commented on both bounties, but I guess I'll fix them anyway. :)

avleen commented 2 years ago

Thanks Rimas :)

Also: yes, perhaps my last message was a little strong, the software isn't riddled with these issues. The vast, vast majority probably come down to unsanitised inputs and there are lots of easy ways we could (and should!) fix them :)

On Wed, Jan 12, 2022 at 11:00 AM Rimas Kudelis @.***> wrote:

Thanks Jamie! I've commented on both bounties, but I guess I'll fix them anyway. :)

— Reply to this email directly, view it on GitHub https://github.com/vexim/vexim2/issues/272#issuecomment-1010918658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDXBOPWSBQBN7PHBGVXI3UVVNMVANCNFSM5DRKBAUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

kaluang commented 2 years ago

Thank you all! I am using vexim for probably around 15 years now and I am still quite happy with it. There are not a lot low maintenance and well working alternatives out there, at least that I know of. And I would like to keep using it, so of course I would be glad if any security issues could be fixed.

runout-at commented 2 years ago

Thanks for all the discussion!

@rimas-kudelis sorry if my comment about php was offending to anybody. this was not my intention. But I won't recommend to use php for any new project and personally I avoid using software written in php whenever possible.

It could be an idea to split exim-config, databases and admin-webui in separate repositories. This way the comment from @avleen would only target the 'old' php code and not moving away from vexim2 completely - to me the vexim2 project is more than just the gui.

rimas-kudelis commented 2 years ago

@runout-at, no hard feelings here. I know it's a personal preference, and I'm not trying to enforce mine on you. And spliting of the repository could make categing to these personal preferences really easy, so, like I said, feel free to push your UI repo to GitHub and propose it as to become an "official Vexim repo" if you wish.

Heck, if your frontend is actually finished enough to be a working replacement of Vexim, we could even delete the PHP scripts we have here and update the README accordingly.

I also have that itch to rewrite the PHP frontend using a modern framework. It's not itching too much, but if I ever decide to scratch it, I'll certainly push the resulting code in a separate repository, not this one.

runout-at commented 2 years ago

I will move this discussion back to #254