http://forum.xda-developers.com/showthread.php?t=442857

It seems as though there is a /system/sbin/sh running in the background with
/dev/console as stdin. That could explain why typing "reboot" and then enter (in
ConnectBot or otherwise) will reboot your phone. If you type "telnetd", telnet into
your phone, and look at the /proc/XX/fd tree for the /system/sbin/sh process, you can
see it clearly.

Yes, see http://android.jim.sh/index.php/ConsoleShell for some more details.  The bug
is in /init.rc and a proposed patch (against
git://android.git.kernel.org/platform/system/core.git) is below:

diff --git a/rootdir/init.rc b/rootdir/init.rc
index 23daa0b..3aee696 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -158,6 +158,7 @@ on boot
 ##
 service console /system/bin/sh
     console
+    disabled
 
 # adbd is controlled by the persist.service.adb.enable system property
 service adbd /sbin/adbd

Funny story behind finding this-

I was in the middle of a text conversation with my girl when she asked why I hadn't 
responded. I had just rebooted my phone and the first thing I typed was a response 
to her text which simply stated "Reboot" - which, to my surprise, rebooted my phone.

Marking as security problem, which will hide this issue until the fix is public. 
This is nothing more than a gesture really since this is now known publicly, but it's
our process for now, so let's follow it.

This is already fixed and is going out in the RC30 build which will be pushed to
users very soon.

Well, it was supposed to hide it. :)  I guess that's not working at the moment.

My phone auto-installed the patch for this over the weekend and I can verify it
works. At least, I can no longer type "reboot" from anywhere and have the phone
reboot, so there's no longer a system shell listening for all input.

Two process-related questions though:

- Shouldn't the fix be showing up in the git repository? I looked at
http://git.source.android.com/?p=platform/system/core.git;a=blob;f=rootdir/init.rc
but the "service console /system/bin/sh" line is still there. Is that not what was
fixed, or is the git repository out of date?

- Shouldn't this bug already contain a patch, show pushes to source control, be
marked fixed-in-next-version, and then be marked fixed after the update was pushed
out? I'm just wondering about the transparency of the bug fix process and how up to
date this tracker is.

IF you don't mind me asking, how does one go about getting these released patches? I
am still on RC19 and apparently RC30 is the latest.

Ed said "I can no longer type "reboot" from anywhere and have the phone
reboot, so there's no longer a system shell listening for all input."

maybe, or maybe they just look for and remove the word reboot,and there IS still a
shell listening

I would like to apologize for all of the bad press the G1 has been receiving as a 
result of this bug, which I originally posted about in the XDA dev forum. Had I 
known the e-mail addresses of anyone at Google I certainly would have notified them, 
and only them. The Android OS is not "plagued" with security issues. It should be 
noted that all operating systems, especially those which are new, will have bugs. I 
would personally like to see more articles praising the Android team for creating 
and sending out the OTA security patch to the millions of phones that have been sold 
to date, within moments of finding out about the issue. That response is what is 
remarkable, not the bug. 

I'd like to know more about the history of the bug and the response too. This is a
good candidate for a postmortem analysis. For example,
- When was it first introduced? It doesn't happen in the emulator.
- What exactly was the timeline from when it was noticed, reported, fixed, tested,
and deployed?
- How did the open source nature of Android help or hinder discovery and resolution?

Grace under fire, transparency, absence of self-censorship, and a track record of
learning from mistakes are some of the hallmarks of a successful open source project.
Instead of being put off by the fact that there was a problem, I think folks will
appreciate knowing how problems are dealt with, as jdhorvat said.
Just my 0.02.

My name is Jonathan, I am a CAD Systems Coordinator from Illinois. My interest in
Android development exists as more of a hobby for now, but I am always on the search
for more knowledge. I want to give everyone as much information as I can about the
matter. I also think a post-mortem analysis for a bug like this would be an excellent
idea, though I'm certain the Android team would have some excellent insight on that
as well. I don't think anything like this will happen again, but the response was
simply remarkable.

This bug was actually found on November 4th, at about 5pm. After I noticed it I
waited until the morning of the 6th to say anything to anyone. I had done a little
searching to see if I could find the name of the person to report it to, or even an
e-mail address, but couldn't seem to find any useful results. I was aware of the XDA
dev forums, and the work being done there, which I had taken much interest in, so I
thought maybe sharing it with them was the only route.

Within a few hours user jimparis on XDA dev was able to answer some of the questions
I had posed, and he added it to a small wiki
(http://android.jim.sh/index.php/ConsoleShell). Another user went ahead and posted my
bug to Google's code forum, which I was unaware even existed. I believe Google was
already working on RC30 for its other jailbreak vulnerabilities, saying as early as
the 6th that they were "currently working with our partners to push the fix out and
updating the open source code base to reflect these changes." Within the early AM on
the 7th, the first AndroidForums members started reporting having received the update.

The fact that Android is open source actually allowed users (jimparis) to track down
the problem to a few lines of code, before Google even knew it existed, which I
suppose saved them at least a little time in a time-critical situation.

I think it is amazing that, within 24 hours, my post in a relatively obscure forum
made it from being an obscure post with few comments, to being part of an
Over-The-Air emergency update, to over a million handsets. Wow. Google didn't waste
any time, and their efforts to put a stop to these vulnerabilities went off without a
hitch. The only complaints some users had would be the timing between updates, but I
see that as a good thing. Obviously there won't be a new root vulnerability every
week; they are disposing of these security issues as they arise, and in time they
will become fewer and far between. It should be noted that there is no such thing as
a perfectly secure system, except maybe for one that isn't turned on or plugged in. I
am comfortable personally, knowing that a device which carries all of my personal
information, if found to be insecure, is likely to be fixed and updated within a day
(confirm?) of the release of information on that exploit, whether that release of
information was to Google or not.



Thanks for listening! And feel free to e-mail me if you have any additional
questions, I may have left something out.

- Jonathan

(No comment was entered for this change.)

There are various times when making a phone call the phone will reboot.  Haven't
figured out what triggers the reboots.  The way they do the internal memory is a
problem since all programs are installed on internal memory, and they also store
everything on internal memory which cannot be expanded.  They seem to want developers
to do everything as far as the apps they should have included in the first place but
they don't give them the full access to the os to build everything.  The web browser
does not work correctly on a significant number of web sites.

(No comment was entered for this change.)