A couple issues

[ShadowHatesYou]

Hello,

A few days ago I received a B3-500gb wifi, and I'm loving it. However, it's not without it's issues.


Issue 1:

Fixed via reflash.


Issue 2:

The web interface doesn't provide an easy method of configuring multiple profiles. I understand most routers don't, but being able to supply secondary IPs to the interfaces(even when in DHCP mode) via webif would be appreciated. In fact, I find the networking configuration options to be quite lacking, as I have no control over whether things are bridged or routed, or control over VLANs. ebtables wasn't even installed by default, despite having a bridged configuration that could benefit.


Issue 3:

There are no local ttys, which kinda sucks.

During my inability to communicate with the B3 I remembered the USB ports, and tried to plugin a USB keyboard to fix the problem headless(eg, type my username and password at the /sbin/login prompt, then do an ifconfig/brctl/whatever blindly). There was a problem with this idea, though. The B3 does not ship with a /dev/tty0, so USB keyboards can't be used as they have no console to output to. There's /dev/tty, and /dev/ttyS0, but tty0 allocation was explicitly commented out in /etc/inittab and the character device is missing in /dev. I uncommented it, and did a `mknod -m660 c 5 0 /dev/tty0`(I grabbed the major from /proc/devices), however it disapeared on reboot. After some fiddling with udev I have /dev/tty0 back, however getty doesn't seem to want to attach at boot.

Is there either a way to make the keyboard(which is properly detected according to dmesg, and I'm able to read keystrokes from it in sysfs) write to ttyS0, or to get a working tty0 on this thing for issuing commands blindly?



Issue 4:

While poking around on my B3, I noticed the following:

shadow@b3:~$ dmesg | grep Kernel
[ 0.000000] Kernel command line: root=/dev/sda1 console=ttyS0,115200 serial=<redacted> key=<redacted> button=0
shadow@b3:~$ cat /proc/cmdline
root=/dev/sda1 console=ttyS0,115200 serial=<redacted> key=<redacted> button=0

What is the key= cheatcode for, and why is mine different from other peoples? I saw this question asked in another post(http://forum.excito.net/viewtopic.php?f=9&t=3372), but it was never answered. In fact, what's button= and serial=? My serial= is different, too. That makes me wonder - are the serial and key cheatcodes related to each other? Some kind of device identification?


Thanks.

[johannes]

Hi!

Issue2:
Agree, the UI is pretty simple, this is on purpose. Most people get confused and afraid of too many settings and our general idea is to keep things simple. For people who like more advanced stuff there is always the command line. Right or wrong but this is our concept.

Issue3:
There IS a physical serial port, however you need some modding to reach it. it's a board-edge connector on the circuit board, which we use in production and when debugging returned units.
Furthermore, you can use an USB-serial-cable to get a console without having to do any soldering. Just plug it in to the usb port, install usbserial and you're done. You won't see the boot log and you won't reach u-boot this way though.

Issue4:
Yes, serial and key is just what they sound like, unique identification of your device. This is burned in flash on the main board, and used as an identifier for the easyfind service (to prevent b3's from stealing each other's names).

[ShadowHatesYou]

Issue 3:

I understand there's a serial port, but I have no idea where my FTDI is(I just moved), and *everybody* has a USB keyboard. Why not spawn a tty0 so people can use a USB keyboard, instead of having to buy a TTL/serial cable? Does that require the kernel to detect a text mode/framebuffer device or something? Or, at the very least, is there a way to send USB HID keypresses to ttyS0?

Issue 4:

This worries me. Under what circumstances are this serial number/key combination provided to the outside world? How is this information accessed from the userland daemon(same as I did?)? Is key escrow being practiced, eg do you have a copy of these keys on your end that could be either compromised or provided to a third party? Is there a real reason a standard service such as dyndns, no-ip, or BIND nsupdate isn't used for this behavior?

[RandomUsername]

This worries me...

Why? What do you suppose would happen if someone got hold of this information?

EDIT: All the alternative services you mention require a username/password combination so what's the difference between that and Easyfind using a serial number/key combination?

[ShadowHatesYou]

I worry because if the information can be queried from the device, then it enables tracking, and I value my privacy. And before you say it, yes, things like SSH provide a cryptographic identity that's tracked just as easily, but that's why I use openvpn. It also facilitates account theft.

The difference inbetween the SN/key combo and a password system is much like the differences inbetween a Biometric door, and a challenge/response system. You can revoke a challenge/response(IE, username:password) if it's compromised, but good luck changing your fingerprints(SN/key) after someone lifts them off a coffee cup(reads them from your device, or you post them here on the forum asking what they are, which several people have done here). It's not implausible(hell, it's *likely*) that a local file inclusion exploit could be found in the WebUI, making irrevocable theft of the Easyfind service possible by simply reading /proc/cmdline once. If it was instead a username/password combo stored in MySQL or a flatfile, at least that could be changed if it was compromised.


PS:
This also makes it really easy for people to *accidentally* compromise their devices credentials. If someone comes here with a problem, and you guys respond "Can we see your dmesg output?", line 14 of that output will contain the devices serial and key.

PPS: Any user on the B3 can read /proc/cmdline, or do 'dmesg', both of which compromise these credentials.

[johannes]

I am following this discussion with great interest.

This information is never "fetched" from B3's automatically. Neither are there any "phone home" from B3 wihtout the user's active decision, however if enabling easyfind, which by definition requires our dns server to know your location, this is a consequence.

I should also mention that there is one other event that will send the key to us - when using the web software update. we have a backend feature we call "hotfix" which we can use to recover devices with issues that the standard aptitude-based updater cannot solve (such as broken updater code etc). These hotfixes are scripts that run pre-update, and are described in the users manual. We have used them a few times so far. And naturally, before running scripts on people's B3's we need to verify both that it is customers B3's that are asking for it, and the B3 also verifies that the script comes from us through some handshake key certification process.

If this is not wanted we urge users to do command-line updates instead.

[ShadowHatesYou]

K, but couldn't the device's MAC be used for this instead for device identification? I see that the OUI 00:22:02 is assigned to Excito Sweden, giving you 16,777,216 (16^6) unique device IDs before requiring another OUI. I see the MAC is also set from around ~0x00000480 on/dev/mtd1, just before the SN/key.

I'm repeating myself here because I editted the post above before realizing you had responded to me, but do you realize that any user on the b3, not just admin, can get these credentials by reading from /proc/cmdline or doing dmesg?

[johannes]

Yes, the MAC could replace the serial, but we chose a separate serial since it's easier in backend maintenance systems (at our production site) having a standard numeric instead of hex numbers etc. What would the gain be to use the MAC?

I want to correct myself aswell, the key is no longer used in the hotfix/update process. B3 validates that the hotfix comes from our servers using a gpg signature, has nothing todo with the key anymore.

So, to conclude: The only purpose of the key is to secure to the easyfind system that the requestor of a change really is the correct B2/B3. You are right that any B3 user can read that key, but a non B3 user cannot (as opposed to locking easyfind to the MAC). Hence if you let nasty people in to your B3 you may get compromised, but I guess you have worse problems anyways if you do that. The same goes for someone hacking into B3 to get that key, if they get that far you probably have worse problems than your easyfind name getting nicked.