Thought about this while driving home from the con this weekend.

What if, when we did an FTP "put" command through the KFTPD interface, the player automatically went into RW mode, and when it was done with the transfer, it went into RO mode again? Similar thing with chmod, mkdir, rm, etc.

It would save us the hassle of doing it every time.

Or is this a security risk?

And I thought I was lazy....

Mmm.. I've been thinking lazy thoughts like that too.

But it would really slow down things like the mirroring software I use, and syncs, and..

Some of the better FTP clients (and even some of the dumb ones) can use connect scripts and disconnect scripts, which could be given commands to set RW on entry, RO on exit. Not the same thing, quite, but close.

But there's other issues two, like multiple simultaneous FTP sessions (yes, I do that sometimes).. just to hard to get it right, and too simple to leave it as is..

-ml

Oh, btw, SITE RW is not needed when just uploading a new kernel to /proc/empeg_kernel

-ml

Yes, I did discover that you don't need to RW the player to send a new kernel.

Is that a security risk?

No worst than anything else that's possible with FTP access.

Set a password if it worries..

Personaly I would say err on the side of security. About the only time I use the HTTP and FTP daemons are on a corperate network. By leaving this requirement in place it adds an extra layer of security by making someone know the proper commands to issue to write to the unit. In addition it would be nice if you did have to issue a SITE RW to flash the kernel as well.

Perhaps add a switch in the config.ini to enable auto SITE RW RO commands.

Nope. Doing SITE RW to flash a kernel is more risky to the player than not doing it. I'm leaving it as-is. The player has no security by default from the manufacturer. There are security options if you need them.

Anybody plugging it into a corporate LAN is probably doing so for use of "advanced features" from Hijack already, so setting the right parameters isn't something unreasonable to expect of them.

Unlike politically correct trends, I'm erring on the site of ease of use here.

Cheers

In reply to:

---

Set a password if it worries..

---

It disturbs me that Hijack is passwordless (both FTP and HTTP) by default. Very Microsoftish!

Services should only be enabled explicitly, not as part of installing an unrelated item.

P.S. Mark, any chance of a link from the Hijack home page to the Hijack FAQ on RioCar.org?

Well, by default, your Empeg doesn't have either installed until you put Hijack on it. People aren't likely to install Hijack on their Empeg w/o first looking at the features, so they are aware of what is going to be enabled when they do. It's not like a certain OS where the features enabled are not documented anywhere..

FAQ link now added, thanks.

And nobody here should be fooling themselves about LAN security. If your player is plugged into a LAN, then anyone with knowledge about Empeg/RioCar players can easily hack into it with JEmplode or Emplode.

Installing Hijack doesn't really increase the risk (hard to increase beyond 100%..), but it does give you tools to better secure it if one wants to do that. Sure, more people know how to use FTP than Emplode, but they cannot damage a thing with FTP unless they have specific Empeg/RioCar/Hijack knowledge, and in that case they already know about Emplode/JEmplode as well.

Cheers

With Emplode/JEmplode and no Hijack, you can't (or shouldn't be able to, at least)

• write to the kernel area of flash
• change the running order (e.g. HTTP "play")
• remove or replace files outside of the music partions (e.g. the player binary), other than config.ini

Any attempts on the player are obvious when the music stops and an unasked-for synchronize begins.

Adding a wide-open Hijack does make me (even more) nervous.

>write to the kernel area of flash

It's possible, in a convoluted fashion, beyond most script kiddies. But it's also relatively harmless, and easy to fix.

>change the running order (e.g. HTTP "play")

There's a play button in emplode (replaces running order).

>Remove or replace files outside of the music partions
>(e.g. the player binary), other than config.ini

But the files on the music partitions are the most important ones. All of the others can be restored to original state with a player upgrade. Music theft, substitution, playlist deletion.. those are the real issues to worry about.

Cheers

Mark,

This may be hideous, ignore it if so

Would it be possible to RW/RO on PUT if the player is currently RO but to have no unusual affect if it is already RW.

This way you could do the good old SITE RW at the beginning of a session to upload a bunch of files and not have the overhead of RW/RO between each file but if you were lazy you could swap a file or two over without having to RW the player.

-Geoff

What I don't understand is why would someone bother to hack an empeg... All they could possibly do is destroy data, and that's rather pointless, as that's what backups are for, or steal songs that are readily available on the net. I mean, As I understand it, there are only 4000 empegs in the WORLD. What are the odds of someone with enough expertise with the empeg actually stumbling on your IP on purpose? I mean, especially since they are so removeable as to be pulled off the network 4-5 times a day?

Has anyone actually been hacked? And if so, what was done?

Exactly.

But Hijack does have a pretty good measure of protection nonetheless, you just have to read the FAQ first and then turn on the parts you like.

-ml

>This way you could do the good old SITE RW at the beginning of a
> session to upload a bunch of files and not have the overhead of
> RW/RO between each file but if you were lazy you could swap a file
> or two over without having to RW the player.

Yeah, it's possible, but I'd rather just leave that to the client software. If your client supports a ".netrc" file (or better), then just stick the RW command in there. Note that issuing a kftpd RW command doesn't do/hurt anything if the drives are already RW.

Cheers

It disturbs me that Hijack is passwordless (both FTP and HTTP) by default.

Hey, guys, be reasonable, this is a frigging car audio! It is meant to be connected to one's *home* machine, probably via USB. It was not meant to reside on corporate LAN or Internet. Those of us who do install Hijack and put our players at mercy of our co-workers are expected to be able to decide whether they need a bit of security provided by Hijack.

That said, a simple password for emplode access via ethernet (resetable via serial and USB connection) *would* be usefull. Perhaps two level of protection - one against changes, another against any access. (Hm, I am I bit behind with Hijack features - perhaps something like that is already there? No, that would require a change emplode.)

What Hijack has for emplode is a "disable_emplode=1" flag in config.ini, which really just disables ethernet access by Emplode.

-ml