Bootstrap XSS
-
I have recently read that there are five XSS vulnerabilities in the Bootstrap framework version that pfSense 2.4.4 uses. Are there any plans to update Bootstrap in 2.4.x or is this more likely to be appear in 2.5?
-
Yeah .... it would be nice to shut down the entire GUI access all together which would take care of such a situation
( all this GUI code and web server would be thrown out of the security equation )
But ... not very practical.
What you should do, even if the GUI (web interface) has no known issues at all : make it accessible by devices you trust - and have this access accessible on a (the) LAN interface you trust. No other devices should be hooked up to that interface.
Put all other devices on a separate LAN (OPTx) interface that has no GUI access.Btw : I don't know of these XSS vulnerabilities are actual harmful, or not, and like you might have guessed, I know how to protect my firewall from any side.
-
Did you actually test to see if the version we use is affected, or are you only going by version number? It's entirely possible we may not be using affected methods or parameters, or are using them in ways that are not affected. I opened an internal bug report to look into an update, though. It is quite an old version that's being used, but we need to be aware of potentially breaking changes.
-
No, I didn't do a file comparison on the code or test for an actual XSS exploit. I simply looked at the version number for Bootstrap that normally appears in Bootstrap's CSS . I made an assumption due to the code being in a 'Vendor' folder hierarchy that it would be as released by the vendor. I assumed that modified code would be under 'pfSense'. Is that an unreasonable assumption?
Bootstrap version number is in
/usr/local/www/vendor/bootstrap/css/bootstrap.min.cssWhile writing this reply I have decided that it is an unreasonable assumption to assume that any code has not been tampered with. I should not blindly trust 'vendor' code that is used in other systems.
Perhaps it is better to use Jenkins or some other CI tool to download and validate official vendor sources and then verify the integrity of every system within my infrastructure that uses them.
For many years I have placed a high degree of trust on pfSense, and I still do. However, my attitude to trust has changed since the OpenSSL Heartbleed discovery. As a user of open source tools I now accept the shared responsibility of being one of the many eyes looking at the code. A software project can benefit by many people scrutinizing code and installations of that code.
Thanks for your post Jimp. It has seeded an idea for a new business to explore next year.
-
The file could be stock and still not affected, it depends on the bug and how the library is used. I haven't looked deeply at that particular issue, but in similar cases in the past we've seen instances where we happened to not use a particular affected component so even though the vendor library was flawed, pfSense was not vulnerable. So it does take a bit deeper analysis than just inspecting version numbers.
Still, it is very out of date, so we are certainly looking at what the impact of updating it will be.
