(if I ever figure out where --web is handled, and I cannot find any documentation on this command line option so far, I guess I can submit a patch to switch it to localhost or to enable the “?localhost” option in root httpd).
can you say more about this? if I am at an internet cafe connected to local wifi, everybody else on the same network can connect to my machine. by default, ubuntu 22.04 has no firewall rules and everybody in the cafe can access my root session, see my files. do try this at home!
macos has a restrictive firewall by default, but if user clicks “yes” on “allow root.exe to accept internet connections?” popup, the problem appears and it is not clear to me how to undo this “yes” to make root secure again. (you cannot try this at home, root is broken on macos 14).
K.O.
@jonas: Dear Ionas, understanding the gravity of the issue, do yo still want @dd1 to go through the bureaucracy of reporting the issue on github as well? - BTW, he just did what is recommended the ROOT7 web page … For completeness, I could also report this issue to CS.
@dd1 : the slice is thin 
would it possible in the near future to ask you question(s) about MIDAS ?
I think, the entry point is here - void TROOT::SetWebDisplay(const char *webdisplay)
(somehow I am not allowed to post even a ROOT github URL)
at a closer look, it seems that everything needed is already implemented in gui/webdisplay/src/RWebWindowsManager.cxx, and binding the ports to localhost is just a matter of changing the defaults:
/// One also can bind HTTP server socket to loopback address,
/// In that case only connection from localhost will be available:
///
/// WebGui.HttpLoopback: yes
///
/// Or one could specify hostname which should be used for binding of server socket
///
/// WebGui.HttpBind: hostname | ipaddress
///
/// To use secured protocol, following parameter should be specified
///
/// WebGui.UseHttps: yes
/// WebGui.ServerCert: sertificate_filename.pem
///
/// Alternatively, one can specify unix socket to handle requests:
Hi,
WebGui.HttpLoopback: yes
It should be default option for the web widgets.
But it was changed only in one place (in C++ code), but remained off in default rootrc file.
I will fix it as soon as possible.
Thanks for pointing out this problem.
Regards,
Sergey
For the time been just create .rootrc file with the entry:
WebGui.HttpLoopback: yes
yep - that works - thanks a lot!
One more question: how would a user control the URL of the created canvas page ?
- in the example below the generated URL ended up being http_://localhost:9791/win1/?key=949902 (the underscore after “http” is not a typo, but a way to fool the forum software)
- how would a remote client know about the “key=949902” part ?
root [0] TH1F* h2 = new TH1F("h2","h2",100,0,100)
(TH1F *) 0x3237a30
root [1] h2->Draw()
!!! ATTENTION !!!
ROOT comes with a web-based canvas, which is now being started.
Revert to the legacy canvas by setting "Canvas.Name: TRootCanvas" in rootrc file or
by starting "root --web=off".
Find more info on https://root.cern/for_developers/root7/#twebcanvas
Info in <THttpEngine::Create>: Starting HTTP server on port 127.0.0.1:9791
key is optional parameter and only used for handshaking between server and client. But canvas URL also works without such parameter.
Only if WebGui.OnetimeKey: yes configured in rootrc file, web widget will response only with such key parameter - which can be used only once.
thanks again!
thank you for the quick solution. please add it to the documentation web page (URL in the OP). please consider posting this information to the ROOT announcements list. all users of ROOT 6.28 must know about this problem. I assume it will be fixed in the next 6.28 point release? or we have to wait for 6.30?
K.O.
sure, ask away. best is to use the MIDAS forum at midas.triumf.ca. Stefan usually answers faster than me.
(answers price list: answer: $1, correct answer: $10, useful answer: $100)
Full documentation about server parameters one can find in RWebWindowsManager::CreateServer() method.
Fix will be apply for next 6.28 release and most probably for 6.30.02.
Thanks everyone for your super useful input. Two comments:
- In the future, please notify us through email at rootdev@cern.ch to give us time to address security issues, rather than making them public immediately. See e.g. Coordinated vulnerability disclosure - Wikipedia and Reporting Security Issues - ROOT
- We are currently documenting the security issue; we are preparing patch releases for all affected production versions still in active maintenance, i.e. at least 6.28 and 6.30.
Thanks again for your help with this, and major apologies for this terrible bug.
More news in the coming days.
Cheers, Axel
Hi Axel,
Now that a release with a patch for the bug is provided, would it be prudent that somebody gets in touch with any known package maintainers and lets them know about the urgency, to hopefully minimise any exploitation time where we can. Some packages will have more CI than others and might pick up on the changes automatically, but best to not rely on this as much as possible.
The ROOT 6.26 and 6.28 pre-compiled binary distributions for Ubuntu 18.04 / x86_64 (“End of Life” April 2028) are missing. Please add them (I assume ROOT 6.30+, which require C++17 or newer, will not be supported anymore).
Hi @James-Carroll
thanks for reaching out - we are using CERN’s connections to talk to the maintainers, apart from ROOT’s usual connections. (Do you think you could help us with snap?)
Cheers, Axel
We don’t have an Ubuntu subscription; for us, Ubuntu 18.04 is EOL. See https://ubuntu.com/about/release-cycle and read carefully what it says on “ESM”.
Cheers, Axel
Thanks, it’s nice to hear that people are getting notified :).
The Snap’s already had patches for the 3 effected branches published, 2 days later about 60% of people have already downloaded them. The autoupdate mechanism is aggressive but definitely shines through in these scenarios! Effected users would also benefit from some of the sandboxing mitigations, the threat is still high, but in theory things such as access to .ssh keys, browser history, config files, network locations, etc, would all have been cut off for effected users which is a nice to have too.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.