Cybersecurity Discussion

[Lukmin1999]

Hello! My name is Lucas. I am an undergraduate at Washington University in St. Louis.

I’m taking a course on cybersecurity, which has a final project where students dive deeper into a security topic of interest.

For my project, my group was hoping we could conduct our own original research on potential security vulnerabilities on Jamulus.

As a user of Jamulus myself, I’ve been able to continue rehearsals with my college a cappella group, despite the pandemic. However, I do worry about the increase of users in the past year. If any system has a security vulnerability, it is not a matter of whether someone finds it, but whether someone exploits it.

For this project, my group will search for (or confirm the lack of) security vulnerabilities Jamulus may have. We would report our findings and discuss potential fixes and/or defenses of attacks in order to prevent them from being exploited.

As pointed out by @pljones in a discussion, “Jamulus does not publish personal ("person"-related) information without user consent.” In addition, Jamulus makes no claims of trust by its anonymous nature (@gilgongo). However, we believe this project is worth doing. Jamulus, like any application, should follow fundamental principles of cybersecurity. It is my group’s wish to confirm that Jamulus follows these principles. Also, it never hurts to be careful.

Based on my own experience with Jamulus, we're currently looking into the potential of a few attacks, including but not limited to:
- XSS attacks
- UDP Spoofing (Or other Denial of Service Attacks, like resource exhaustion or reset attacks)
- Session hijacking?

A lot of our research can be done by looking at the source code. However, our research would not be complete without performing actual attacks on a server, which I am asking permission to do here. We would make our own server for this project; we would never have to perform an attack on someone else's server, nor do we ever intend to. Still, we thought it best to let you know this for full transparency.

If you have any questions about this project, or if you are aware of potential security risks that you would like us to look into, please let me know!

[gene96817]

Good to hear you have chosen Jamulus for your project. How much time do you have for this research? I would be very interested in following your project.
Since there is not authentication, everywhere Jamulus uses an IP address is vulnerable to spoofing. The spoofing can be used for denial of service or impersonation or man-in-the-middle attacks. It could be cool to demonstrate a replay attack to inject delay and echos.

[hoffie]

Hi!

This sounds great! Thanks for considering to work on Jamulus as part of your project and thanks for asking here beforehand. I'd certainly welcome this! :)

However, our research would not be complete without performing actual attacks on a server, which I am asking permission to do here. We would make our own server for this project; we would never have to perform an attack on someone else's server, nor do we ever intend to. Still, we thought it best to let you know this for full transparency.

If your tests and attacks are solely directed at your own infrastructure as you write, then this should be fully OK.

if you are aware of potential security risks that you would like us to look into

There is a rather long thread about potential security issues here: #314

From my perspective, implementation-level issues would be most interesting:

• Is there any potential for code execution?
• Is there any potential for unwanted filesystem access (arbitrary file read/write)?
• Is there any potential for crashing clients or servers remotely?

My hope is that nothing is to be found in this area, but if there is, this would be a very high priority issue to solve.

There are some things where Jamulus may not match the same assumptions which people expect from other server software or platforms:

• UDP spoofing, reflection attacks, resource exhaustion as listed here: Discussing potential security issues #314 (comment)
• Authentication
• Encryption

These are architectural concerns where potential solutions (e.g. TCP) are discussed, but are rather far away from being decided upon or even implemented.

Would you be OK with sharing your potential findings privately first? We are still ramping up documentation in various places, including that for our security process, but I'd prefer if we had some time to develop fixes for potential issues and only publish the full vulnerability details when fixed versions are available for download.

Do you have some timeline when to start and when results would be expected?

Kind regards,
Christian (just my personal opinion, without having talked about it with other team members)

[Lukmin1999]

Hello! Sorry for the late response. I'm thrilled to see this project being supported, and I'll be sure to remain active with communications here.

How much time do you have for this research?

Do you have some timeline when to start and when results would be expected?

The final project for this course is due the 7th of May, so we will be conducting our tests for this project within this time.

We haven't made a complete timeline for goals quite yet, but the general flow of our project will be:

April 5 to April 11, analyzing the source code, bringing group members that aren't familiar with Jamulus as an application up to speed, and creating a list of potential vulnerabilities.

April 11 to April 25, conducting tests and determining whether our list of potential vulnerabilities can be practically exploited.

April 25th to May 5th, writing up our findings.

Would you be OK with sharing your potential findings privately first? We are still ramping up documentation in various places, including that for our security process, but I'd prefer if we had some time to develop fixes for potential issues and only publish the full vulnerability details when fixed versions are available for download.

I would love for this to happen! Realistically, we could report our findings to contributors after our tests and before we actually submit our project; this would mean some time between April 25th and May 5th. Of course, our group can and will continue to communicate here during our process of testing. Do you have any preference as to where we can privately post our findings?

[hoffie]

Thanks for the details.

Do you have any preference as to where we can privately post our findings?

Please use [email protected] to contact the main developers directly. In my opinion, abstract public progress documentation would be fully OK ("We've found 5 potential issues"), but if there are actual bugs to fix, we'd prefer to get the details privately beforehand so that a fix can be developed.

[gene96817]

From my perspective, implementation-level issues would be most interesting:

I would add, is there an opportunity to inject malware that is then distributed to the clients?

[dzpex]

Hi,
I have a private server. Its about two month that i observe abnormal connections to my server.
I see that 3 differet IP addres was connected to my server for 30sec. No audio no name.
Only 30sec. per Times.

This connections are on different moment of the day.

[ann0see]

Sounds strange. However to raise attention, please open a new discussion