Bug 51603 - Apache accepts completely bogus HTTP requests (possible security hole)
Summary: Apache accepts completely bogus HTTP requests (possible security hole)
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.19
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2011-08-02 20:34 UTC by Mikael Lyngvig
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Lyngvig 2011-08-02 20:34:11 UTC
Here are access.log entries for strange machines (worm infested machines?) that hammer on my Apache server with all sorts of completely bogus HTTP requests that are ACCEPTED by Apache.  Apache apparently sends something back to the remote end and I'd really like to know what data it is sending across the wire:

190.3.214.212 - - [02/Aug/2011:05:48:09 +0200] "F6)\xa1\xa8\x91\xb5z\x15\xb3\xfa\x19\xe0R\x16\xccIG_\x012\x80\x162\xec\xf5C1\xa7" 200 847
93.166.90.65 - - [02/Aug/2011:01:23:42 +0200] "\xc1D*\xe5/$gcin\x8a\x1f-I\x16\xf5\xf7\xa2\x97\xb8\x16B\xc7\x95\xae\x11\x99W\x80z\xb8\xa0\x03{\x87\x1e\x19\xe5\x02\x92\xb9\x84\x84" 200 847
92.40.253.152 - - [02/Aug/2011:00:33:12 +0200] "\x12`\xf1J\xc7\xb0c\x149\b\x0e\xdb\xc7\xde\xac" 200 847
213.125.79.2 - - [01/Aug/2011:17:32:04 +0200] "\xab\xf4+r\xd8\x8f6\xf2\x82\xba\x16\x1a\x8f\x1d\x037\xd7lu\x87k\x90|\x1ax\xec\xdf\xc9?\x8c\xfbjX\x96\xfe\xbe\xc2l\xf3J\xda\xd2\x87!\x94\xb1\x1c\xf2\x02p\x02\xab-\xc1\xe4`\xf7\xde" 200 847
212.183.140.13 - - [01/Aug/2011:18:25:45 +0200] "\x9a\\(|p\xb0\x9aoF\xa6]u\xaf\xb8\x84\x0e\xa9'_\xd1\xb2\xa1\x9aU\x17K\x83\xe2\xb6\x06\xfe4\x14JO\xf8\xa2\xc4\xbcBT\xb9\x93\xb9\xcf\xea\xc9\xd5" 200 847
213.125.79.2 - - [01/Aug/2011:18:46:40 +0200] "\bU?\xc0\x1ap\xce\x82_" 200 847

As far as I know, which is rather little in this particular case, Apache should return an error whenever it encounters a malformed HTTP request.


Sincerely,
Mikael Lyngvig
Comment 1 Ruediger Pluem 2011-08-03 18:31:43 UTC
Please provide your logging configuration.
Comment 2 Mikael Lyngvig 2011-08-03 18:42:20 UTC
The logging configuration is the default logging configuration; I have changed nothing:

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

<IfModule log_config_module>
    #
    # The following directives define some format nicknames for use with
    # a CustomLog directive (see below).
    #
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

    <IfModule logio_module>
      # You need to enable mod_logio.c to use %I and %O
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>

    #
    # The location and format of the access logfile (Common Logfile Format).
    # If you do not define any access logfiles within a <VirtualHost>
    # container, they will be logged here.  Contrariwise, if you *do*
    # define per-<VirtualHost> access logfiles, transactions will be
    # logged therein and *not* in this file.
    #
    CustomLog "logs/access.log" common

    #
    # If you prefer a logfile with access, agent, and referer information
    # (Combined Logfile Format) you can use the following directive.
    #
    #CustomLog "logs/access.log" combined
</IfModule>
Comment 3 Eric Covener 2011-08-03 18:45:08 UTC
> I'd really like to know what data it is sending across the wire

Can you capture and post what the response is?
Comment 4 Mikael Lyngvig 2011-08-03 19:32:59 UTC
I have checked the file sizes against the known website files and it appears that Apache returns the root item (GET /), in my case index.php, to the client.  So no security issue, just weird behavior.  I guess Apache should reject all malformed HTTP requests rather than returning the root item.
Comment 5 Jeff Trawick 2011-08-03 20:19:20 UTC
I haven't looked, but is it mod_ssl returning the speaking-non-SSL-on-SSL-port message?
Comment 6 Mikael Lyngvig 2011-08-03 21:00:27 UTC
Hmm, I tried opening the URL as http://www.archangel.dk (the website), https://www.archangel.dk (shouldn't be open as the firewall blocks it) and https://www.archangel.dk:80.  The last attempt gave this result:

90.185.163.243 - - [03/Aug/2011:22:53:18 +0200] "\x16\x03\x01" 200 1279
90.185.163.243 - - [03/Aug/2011:22:53:18 +0200] "\x16\x03\x01" 200 1279

I simply don't know enough HTTPS and HTTP to say whether it is really an error or just somebody hammering on my website using SSL on port 80, which could possibly explain the "bizarre" reaction by Apache that I am seeing.

I can say that mod_ssl is not loaded.

I don't know if there's really a problem at all or if it is just me being hyper-aggressive over somebody probing my website with SSL packets on port 80.
Comment 7 William A. Rowe Jr. 2018-11-07 21:09:08 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.