Reply
New Member
Posts: 1
Registered: ‎11-30-2015

Re: Open call ubnt for Open source firmware

++;

New Member
Posts: 15
Registered: ‎05-31-2014
Kudos: 3
Solutions: 1

Re: Open call ubnt for Open source firmware

+1

New Member
Posts: 3
Registered: ‎06-29-2016

Re: Open call ubnt for Open source firmware

+1

Deleted Account
Posts: 0

Re: Open call ubnt for Open source firmware

+1

New Member
Posts: 28
Registered: ‎06-08-2015
Kudos: 2

Re: Open call ubnt for Open source firmware

YESS +10000000000000

 

Would be awesome to be able to use my 10 power bars the way I want!

Regular Member
Posts: 466
Registered: ‎08-29-2012
Kudos: 296
Solutions: 12

Re: Open call ubnt for Open source firmware

+1

Emerging Member
Posts: 83
Registered: ‎11-08-2014
Kudos: 52

Re: Open call ubnt for Open source firmware

YES!  Or hopefully someone will reverse engineer!

Emerging Member
Posts: 87
Registered: ‎01-17-2013
Kudos: 2
Solutions: 1

Re: Open call ubnt for Open source firmware

+1

Emerging Member
Posts: 49
Registered: ‎05-13-2014
Kudos: 12
Solutions: 3

Re: Open call ubnt for Open source firmware

+1. 

 

 

Emerging Member
Posts: 53
Registered: ‎08-25-2011
Kudos: 7
Solutions: 2

Re: Open call ubnt for Open source firmware

Absolutely not.

From a security perspective, this is a very bad idea.

 

When the software is EOL and no further updates will be made, the only thing we have left is the obscurity of closed-source.  While I appreciate (and prefer) open-source solutions, the model only works if someone is going to fix bugs.

Highlighted
Emerging Member
Posts: 76
Registered: ‎03-04-2015
Kudos: 34
Solutions: 4

Re: Open call ubnt for Open source firmware


hpram99 wrote:

Absolutely not.

From a security perspective, this is a very bad idea.

 

When the software is EOL and no further updates will be made, the only thing we have left is the obscurity of closed-source.  While I appreciate (and prefer) open-source solutions, the model only works if someone is going to fix bugs.


 

On the contrary, security is only achievable via an open sourced setup after the original vendor has stopped providing maintenance.

 

The security bugs will get discovered with or without access to the source code (indeed, most such bugs are found through fuzzing, black box testing, or reverse engineering, not source analysis, even when source code is available). At least with open source (and free as in freedom) code there is the chance for the community to fix such bugs. With closed source code, once the bug is discovered, there's little anyone can do and the hardware becomes far less valuable.

Established Member
Posts: 1,750
Registered: ‎10-28-2010
Kudos: 1204
Solutions: 23

Re: Open call ubnt for Open source firmware


hpram99 wrote:

Absolutely not.

From a security perspective, this is a very bad idea.

 


What are you talking about?  The current firmware has vulnerabilities with active exploits in the wild.  

 

It should be fixed or open sourced so that the community can fix it.

Senior Member
Posts: 3,349
Registered: ‎02-16-2008
Kudos: 2455
Solutions: 38

Re: Open call ubnt for Open source firmware

^ Yup.

 

I've got extensive mFi installations, and as a software guy I would have personally put significant effort into fixing many items.

 

Change the name, slap it on github with the usual warnings.

 

 

 

 

If it ain't broke, fix it anyway
To avoid the Gates of Hell, I use Linux
Professional Electron Wrangler
Emerging Member
Posts: 53
Registered: ‎08-25-2011
Kudos: 7
Solutions: 2

Re: Open call ubnt for Open source firmware

You're partly correct, and as I mentioned I'm a fan of open source software models.

 

However, this only works in practice with the following assumptions

1. The code can be updated, contributions are accepted.

2. The community actually has contributors that care to invest personal time.

3. The community contributor follows best practices.

 

My job wouldn't exist if developers followed best practices.

Regular Member
Posts: 609
Registered: ‎09-17-2013
Kudos: 143
Solutions: 5

Re: Open call ubnt for Open source firmware

[ Edited ]

hpram99 wrote: 

My job wouldn't exist if developers followed best practices.


Cat LOL

 

Actually, most of the ubnt products I have used, have standard software in them. All of which are currently maintained and has developed a bunch of bugs. Even openssl had several issues, as many of the other base items. Hell, even your cell phone is a major flaw, since the ss7 has be hacked and anyone can listen upon you.

 

Being ported over to github, would allow for several advantages:

  • Easily correct vulnerability that are part of the os
  • Allow to find problems, before others exploit them (there are a bunch of zero day attacks)
  • Easily branched to allow for an extended life of the product
  • Probably would only address cpu issues, and not the dsp
  • Assuming that you don't make things worse, you could even roll your own needs into the software
  • Probably the majority of the users can't roll their own firmware, so it would allow us to continue using our mfi products with some confidence

 

Hiding your head in the sand, wont prevent attacks. Security isn't in hiding the details, but insuring there aren't holes that can be attacked. If that wasn't the case, windoze would never be attacked. Remember the units are running common software, with the mfi sitting upon

 

If you take the time, you probably would find one or two attack fronts already. My biggest concern is that there might be something proprietary in the vyatta release

 

Most iot devices are really bad. Ubnt being an internet company, seems to have done most things right (hopefully Cat Wink). Still for a closed system, it has had some specific problems. Look at this

 

Some units are running critical applications for us, and we would have a major issue if these get hacked. For instance, we have one that is connected to a large freezer. Besides getting the energy use info, it protects the compressor against damage because of voltage extremes. Of which we just had one episode last week, when the mains reached 150 V!

Established Member
Posts: 1,596
Registered: ‎10-11-2009
Kudos: 327
Solutions: 6

Re: Open call ubnt for Open source firmware

Support with UBNT regarding mFi:

 

-----------------------------------------

 

So our techs ordered a bunch of mFi for monitoring environmental conditions at tower sites. Based on their experience with Unifi they anticipated it to be pretty straight forward and to work well for our needs. They did not realized when ordering from Master Distributors that this product lines development is “indefinitely on hold”. We are past the return time frame to the distributor but we would like to be refunded. Our techs messed with this platform for ~90min trying to get a clean controller install to launch in browser, the server is a 2012 R2 VM to and they were spinning their wheels with perceived java issues. We don’t have time to mess with something UBNT themselves sweeping under the rug and would appreciate our money back or a firmware update to bring these controllers into our Unifi multisite controller.

 

Russell M

 

-----------------------------------------

 

Hi Russell,


I apologize for the issue you're facing.

We don't have money back policy available. Could you please let me know the Java version you're using on the Server 2012 R2? have you tried the mFi controller on any other machine?

Thanks!
Ubiquiti Networks

 

-----------------------------------------

 

It’s the same 2012R2 64bit VM template we used for the basis of most of our servers, including our current multi-site unifi controller and AirControl2 controller. We tried the latest 64bit java version 8 U102, and 32bit version 8 U45.

 

Russell M

 

----------------------------------------- 

 

Hi Russell,

Would it be possible to download Java 7 and check?

Thanks!
Ubiquiti Networks

 

-----------------------------------------

 

It worked using a java 7 version from 2013 and it seems to be MAC based layer 2 only?!? This is a far cry from what we’ve come to expect in the big brother Unifi line. Last we knew this was still an active product and could be found in the products section of the website. To remove it from the website, not put out any software updates keeping it secure, but not officially discontinue it is poor form of Ubiquiti.

 

We need a refund, credit, of firmware/software update to roll this into our Unifi multi-site management platform.

 

Russell M

 

-----------------------------------------

 

Hi Russell,

I apologize for the trouble caused.

There are not charges for the software and is free of charge.

Also, Yes, there is a limitation that the software only works with Java 7 but you can use Java 7 and Java 8 both in the same computer without any issues.

I know this is a bit of a convenience but that is the only way for now to use the mFi controller.

If you have any other questions, please let us know!

Thanks!
Ubiquiti Networks

 

-----------------------------------------

 

That’s cute, you say the software is “free of charge”, like it’s of no consequence or a frivolous perk in this product line.  Adding that it’s a, “..bit of a convenience” (you meant inconvenience) that the product line as a whole is being shelved/discontinued without proper public notification and is no longer maintained at even a basic level.  You guys should be ashamed offering these shameless unaccountable excuses for poor product line management.  Feel free to pass this sentiment on to Robert.

 

Russell M

Emerging Member
Posts: 53
Registered: ‎08-25-2011
Kudos: 7
Solutions: 2

Re: Open call ubnt for Open source firmware

Certainly not trying to prevent attacks, just reduce risk.  Nothing can prevent attacks.  Even closing holes isn't a perfect solution, there will always be attack vectors.

 

Porting to github would address the ability to contribute, but a few things that pop out at me.

 

In over 2 months, only 49 people have +1'd this thread.  How many do you think are developers, willing to sift through (According to Ubiquiti themselves) bad code, and make security-minded changes?   Lets compare that to your SS7 example, or OpenSSL for that matter.  That's a user base in the millions, and there's some very serious corporate interest in these products, which means paying very smart people a lot of money to scrutinize the code.  mFi is a niche product, and the open-source ideology is that more eyes means less bugs, right?  What good would it do when so few people own, less care, and even less can contribute?

 

Who's going to announce to all the product owners that the source code has been released?  Would this be good or bad publicity?

 

Everyone wants it open source to add features, when no one is liable, is security really going to be a consideration?

 

And you're right, no app is completely secure, if mFi were used in an enterprise environment, we would need to work on migrating away from an unsupported product line.  But then again, maybe we shouldn't use prosumer beta equipment in the enterprise environment.

 

 

We're asking for Ubiquiti and it's consumers to accept more risk.  If the project is being abandoned because the code is so bad it can't be cleaned up, I sincerely doubt Ubiquiti is going to spend the time to properly prepare, notify, and release that code publicly.

New Member
Posts: 34
Registered: ‎06-03-2015
Kudos: 14
Solutions: 1

Re: Open call ubnt for Open source firmware

+1

Member
Posts: 215
Registered: ‎02-05-2012
Kudos: 71
Solutions: 2

Re: Open call ubnt for Open source firmware

[ Edited ]

hpram99 wrote:

 

(...)

In over 2 months, only 49 people have +1'd this thread.  How many do you think are developers, willing to sift through (According to Ubiquiti themselves) bad code, and make security-minded changes?   Lets compare that to your SS7 example, or OpenSSL for that matter.  That's a user base in the millions, and there's some very serious corporate interest in these products, which means paying very smart people a lot of money to scrutinize the code.  mFi is a niche product, and the open-source ideology is that more eyes means less bugs, right?  What good would it do when so few people own, less care, and even less can contribute?

 

(...)

 

Who's going to announce to all the product owners that the source code has been released?  Would this be good or bad publicity?

 

Everyone wants it open source to add features, when no one is liable, is security really going to be a consideration?

 


 

IMO right now, with active exploits in the wild "security" is effectively non-existent;  sure there are sort of mitigations for those, but really I don't think you/anyone can consider the current state "secure" under most generally understood meanings of the word.

 

So I would argue that the current level of "security" wouldn't be significantly impacted by the release of source code (of course I am assuming there aren't things like backdoors hardcoded in *cough juniper* -- but if there are I think knowing that would be more valudable than everything else we are discussing here).   

 

To the second point - essentially (caveat: I am paraphrasing - but not intending to misrepresent) "the project is complex, and there are limited amount of people who have the time/skill/capital to go through and do something with the source code on what is a much more niche platform (i.e. no WRT54GL, etc.).    This is probably true, but I would say that it's definitely *not* going to happen without the release -- and really it's slightly more "binarized" than it sounds;  we don't need X percentage of contribution for Y number of people -- really if something happens or not probably depends on one person with the skills/time/interest to dedicate a significant chunk of that to getting something going.  Could be on their free time/hobby, or it could be funded internally by a company/corporation that sees a reasonable ROI on putting 1 person on this for 3-6 months.  

 

Finally, what comes out of this doesn't have to be "fixing" all of the current MFi platform -- an open source project wouldn't have the same requirements, etc. as UBNT does.    The whole controller portion could be dropped, and each device could perhaps have a small web app and api to report data, or something else.  

 

From the point of view of a person who has purchased these they are basically dead weight.  They are pretty useless without the controller software, and with no updates coming ever for that java 7 EOL'd in April, it's pretty much already dead.    

 

----

 

I suspect the not open sourcing it is probably a confluence of

 

1 - Corporate policy;  has UBNT ever open sourced anything?  (Asking here, not sure) -- if not then corporate probably has to figure out what this "means", etc.

2 - Source code review;  need time/money for people to make sure licensed IP, etc. isn't going out, and that everything they have done is kosher (GPL issues without re-releasign, etc. -- i.e. there's a chance there were existing violations, but people just don't know about them - and this potential release could increase liability).

3  - Low ROI;   what does open sourcing it give UBNT?  I think they have already decided to burn whatever credibility they had with customers of those lines  (specifically the fact that they continue to sell products through distributors (As opposed to recalling) which really have effectively no meaningful support.   If  they are willing to do that, then their reputation obviously isn't a concern;   that said, open sourcing it isn't going to make people appreciate them; return to buy other products.  It may help lead to a solution for the customer, but I dare say (as a customer) further purchases wouldn't be from ubiquity  (fool me once, shame on you... fool me twice....).   

 

 

Regular Member
Posts: 757
Registered: ‎04-17-2013
Kudos: 324
Solutions: 36

Re: Open call ubnt for Open source firmware

+1 from me as well.

 

If there's no willingness to open source code, what about allowing reverse engineering / etc? Building a better mfi controller wouldn't be impossible, firmware on the devices themselves would be trickier.

 

I can't speak for the mports, but the mpower devices have been fantastic for me, for everything for a programmable reptile light right over to a remote server rebooter.

 

 

Linux / Network / ISP / Virtualization Geek for Hire
Reply