Thanks for the report.

Your statement in #4 is vague. Can you please describe more precisely what you are doing and what behavior you are seeing?

I am seeing that when I type keyboard shortcuts (ctrl+ c specifically) I get the screen showing "^C" and and font and size is the same as a Linux terminal, and ad chrome OS is Linux based this may be a way to get a terminal without authorization for ~7 sec which, with a micro controller, possible to do damage. This may also affect the "admin does not allow dev mode screen" when the battery is almost out of charge.

Did I clarify #4?

mnissler@: Are you able to comment on this? I think just means some keystrokes are getting echoed, which likely isn't an issue, but I would appreciate somebody with more knowledge of ChromeOS to have a look.

Hm, I'm not aware of such a screen present in the later boot stages, so it's most likely shown by early firmware. Adding firmware people to clarify what that screen is, what code draws it, and whether the console is active at that point.

322997am: Can you clarify which device model you're seeing this with?

Was tested on a dell chromebook 11 3120. 

Also, this screen is present when the OS has booted ( or tries to boot but the battery is low)

Re comment #7: So is this shown before or after the chrome logo boot screen? Maybe we still have our wires crossed, can you describe the screen in more detail? White background, battery icon in the center? Any text?

So after the chrome boot screen("chrome" in the center) the flashing red battery appears where if I type ctrl+c for example(or any other shortcut) it returns ^C (or the shortcut return that happens in a terminal)in the same font and size as a terminal would. I was wondering if this could be somehow exploited

rspangler@: can you enlighten me on what screen we're talking about here?

I'm pretty sure this is frecon accepting console input when it's displaying a bitmap/animation.  I don't think it's connected to a tty, which limits the damage it can do. 

We noticed similar behavior when we ported the recovery installer to use frecon.  It's also likely visible at the dev wipe screen.

In some modes, frecon now accepts escape sequences to load bitmaps and draw on the screen.  Normally that's driven from the init script via a pty, but we noticed it was also possible to spam those sequences in from the keyboard (we actually used that to debug some issues.)  It's pretty good about sanity-checking those inputs, but I don't think we've had formal security review of that code.  

+dbehr (frecon owner) and shchen (ported the recovery installer).

rspangler@: Thanks for providing more context.

After looking a bit more, I'm pretty sure we're talking about the display_low_battery_alert script, which relies on frecon to animate a red battery icon on black background. I've confirmed that it indeed echos input. Looking at the frecon code, it looks like we don't have a shell attached, so this is not a security issue.

That said, for UX reasons and in order to avoiding unnecessary exposure due to parsing untrusted input we should not process any keyboard input when frecon is merely used to display images on screen. I'll file separate bugs for that.

Filed issue 653466 for improving frecon to ignore input when appropriate. Closing this bug now since nobody has come up with a plausible way to exploit this.