The service could not bind instance %1. The data is the error code.For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.

Details
Product: Exchange
Event ID: 115
Source: IMAP4SVC
Version: 6.5.0000.0
Message: The service could not bind instance %1. The data is the error code.For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.
   
Explanation
This error may be seen in the application log after you configure and attempt to start additional virtual servers for the Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), or Internet Message Access Protocol Version 4 rev1 (IMAP4) services in Exchange 2000 Server. Also, the virtual servers that you added do not start.

This issue can occur because TCP/IP, which includes the SMTP, POP3, and IMAP4 protocols, requires a unique socket for each instance. A TCP/IP socket is composed of an Internet Protocol (IP) address and Transmission Control Protocol (TCP) port pair. To generate a unique socket, either the TCP port or the IP

address of each instance must be unique to the given virtual server.

   
User Action
Provide a unique IP address for each additional virtual server.

Related:

() The database page read from the file “” at offset for bytes failed verification due to a page checksum mismatch. The expected checksum was and the actual checksum was . The read operation will fail with error . If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

Details
Product: Exchange
Event ID: 474
Source: ESE
Version: 6.5.6940.0
Component: Microsoft Exchange Extensible Storage Engine
Message: <process name> (<process id>) <storage group name>The database page read from the file “<file name>” at offset <value> for <number> bytes failed verification due to a page checksum mismatch. The expected checksum was <number> and the actual checksum was <number>. The read operation will fail with error <error code>. If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.
   
Explanation

ESE Event ID 474 indicates that a database page read failed verification due to a page checksum mismatch. This essentially means that the particular database page referenced within the Microsoft Exchange Information Store service file named (such as priv1.edb) is corrupt. Possible symptoms are as follows:

  • Users cannot send or receive e-mail messages.
  • You cannot start Microsoft Outlook on your client computer.
  • Online backups fail to complete with a -1018 checksum error.
  • Online defragmentation reports a -1018 checksum mismatch error.

This error is typically the result of a hardware malfunction. The associated checksum mismatch -1018 error indicates some type of hardware error 99% of the time.

   
User Action

After a system administrator encounters a -1018 error, if the administrator runs diagnostic hardware tests against the server and these tests report no issues, the administrator might conclude that Exchange must be responsible for the issue because the hardware passed the initial analysis. However, in case after case, further investigation by Microsoft or hardware vendors uncovered subtle issues in hardware, firmware, or device drivers that are actually responsible for damaging the database file.

Ordinary diagnostic tests might not detect all of the transient faults for several reasons. Issues in firmware or driver software might fall outside the capabilities of diagnostic programs. Diagnostic tests might be unable to adequately simulate long run times or complex loads. Also, the addition of diagnostic monitoring or debug logging might change the system enough to prevent the issue from appearing again.

The first step is to use one of the three methods below to move the existing datbases to new hardware:

  • Obtain new hardware and install a second server in the Adminstrative Group and use Move Mailbox to move the mailboxes to the new server.
  • ExMerge the mailboxes out to .pst files and then ExMerge in to a new machine with the same name.
  • If there is no backup and Move Mailbox is not an option, the last resort will be to repair the database using Eseutil /P and Isinteg -fix. You will still need to ExMerge out all the data after the repair and ExMerge back into new hardware.

The second step is to diagnose and correct the original hardware problem by checking the system log, and running extensive tests from the hardware manufacturer on the hardware, firmware, raid controllers, and device drivers. Then you can use Move Mailbox to move the users back, or restore from online back to the repaired machine.

Definitely do not simply repair the existing database or restore from online backup until the hardware errors have been diagnosed and corrected. You must diagnose and correct the hardware errors before repairing, restoring, moving your mailboxes back, or ExMerging your data back or the ESE Event ID 474s and -1018 errors will come back because the root cause has not been fixed.

Related:

%1 (%2) %3 The database page read from the file “%4” at offset %5 (database page %10) for %6 bytes failed verification due to a page checksum mismatch. The expected checksum was %8 and the actual checksum was %9. The read operation will fail with error %7. If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

Details
Product: Exchange
Event ID: 474
Source: ESE
Version: 6.5.7596.0
Message: %1 (%2) %3 The database page read from the file “%4” at offset %5 (database page %10) for %6 bytes failed verification due to a page checksum mismatch. The expected checksum was %8 and the actual checksum was %9. The read operation will fail with error %7. If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.
   
Explanation

ESE Event ID 474 indicates that a database page read failed verification due to a page checksum mismatch. This essentially means that the particular database page referenced within the Microsoft Exchange Information Store service file named (such as priv1.edb) is corrupt. Possible symptoms are as follows:

  • Users cannot send or receive e-mail messages.

  • You cannot start Microsoft Outlook on your client computer.

  • Online backups fail to complete with a -1018 checksum error.

  • Online defragmentation reports a -1018 checksum mismatch error.

This error is typically the result of a hardware malfunction. The associated checksum mismatch -1018 error indicates some type of hardware error 99% of the time.

   
User Action

To resolve this error, do one or more of the following:

Related:

TCP/IP has reached the security limit imposed on the number of concurrent (incomplete) TCP connect attempts.

Details
Product: Windows Operating System
Event ID: 4226
Source: Tcpip
Version: 5.2
Symbolic Name: EVENT_TCPIP_TCP_CONNECT_LIMIT_REACHED
Message: TCP/IP has reached the security limit imposed on the number of concurrent (incomplete) TCP connect attempts.
   
Explanation

The TCP/IP stack in Windows XP with Service Pack 2 (SP2) installed limits the number of concurrent, incomplete outbound TCP connection attempts. When the limit is reached, subsequent connection attempts are put in a queue and resolved at a fixed rate so that there are only a limited number of connections in the incomplete state. During normal operation, when programs are connecting to available hosts at valid IP addresses, no limit is imposed on the number of connections in the incomplete state. When the number of incomplete connections exceeds the limit, for example, as a result of programs connecting to IP addresses that are not valid, connection-rate limitations are invoked, and this event is logged.

Establishing connection–rate limitations helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in failed connections, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program.

Connection-rate limitations may cause certain security tools, such as port scanners, to run more slowly.

   
User Action

This event is a warning that a malicious program or a virus might be running on the system. To troubleshoot the issue, find the program that is responsible for the failing connection attempts and, if the program might be malicious, close the program as follows.

To close the program

  1. At the command prompt, type Netstat –no
  2. Find the process with a large number of open connections that are not yet established.These connections are indicated by the TCP state SYN_SENT in the State column of the Active Connections information.
  3. Note the process identification number (PID) of the process in the PID column.
  4. Press CTRL+ALT+DELETE and then click Task Manager.
  5. On the Processes tab, select the processes with the matching PID, and then click End Process.If you need to select the option to view the PID for processes, on the View menu, click Select Columns, select the PID (Process Identifier) check box, and then click OK.

Related:

Private bytes consumption changed from %1 to %2. Statistics: %3

Details
Product: Exchange
Event ID: 15003
Source: MSExchangeTransport
Version: 8.0
Symbolic Name: PrivateBytesUtilizationChanged
Message: Private bytes consumption changed from %1 to %2. Statistics: %3
   
Explanation

This Warning event indicates that the memory that is used by the EdgeTransport.exe process on a Hub Transport server or an Edge Transport server has experienced a change in utilization level. This system resource is known as private bytes consumption and is monitored as part of the back pressure feature that monitors utilization levels for system resources.

For private bytes consumption, the following levels of resource utilization are applied:

  • Normal   The resource is not overused. The server accepts new connections and messages.

  • Medium   The resource is slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, the server rejects new connections and messages from other sources.

  • High   The resource is severely overused. Full back pressure is applied. All message flow stops, and the server rejects all new connections and messages.

   
User Action

If the event indicates that the private bytes consumption level decreased from High to Medium or from Medium to Normal, no user action is required. If the event indicates that the private bytes consumption level increased from Normal to Medium or from Medium to High, you can perform the following actions:

  • Do nothing. The back pressure feature will stop accepting new messages and connections on the server. Existing messages will be delivered until the private bytes consumption level on the server returns to Normal.

  • Install more memory in the server. By default, the High level of resource utilization for private bytes consumption is 75 percent of the total physical memory or 1 TB, whichever is less.

  • Increase the default values of the Normal, Medium, and High resource utilization levels for private bytes consumption.

For more information about back pressure, see Understanding Back Pressure.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related:

VU#633847: NTP.org ntpd contains multiple denial of service vulnerabilities

Vulnerability Note VU#633847

NTP.org ntpd contains multiple denial of service vulnerabilities

Original Release date: 21 Nov 2016 | Last revised: 21 Nov 2016

Overview

NTP.org ntpd prior to 4.2.8p9 contains multiple denial of service vulnerabilities.

Description

NTP.org’s ntpd prior to version 4.2.8p9 contains multiple denial of service vulnerabilities.

CWE-476: NULL Pointer Dereference – CVE-2016-9311

According to NTP.org, "ntpd does not enable trap service by default. If trap service has been explicitly enabled, an attacker can send a specially crafted packet to cause a null pointer dereference that will crash ntpd, resulting in a denial of service. Affects Windows only."

CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’) – CVE-2016-9310

According to NTP.org, "An exploitable configuration modification vulnerability exists in the control mode (mode 6) functionality of ntpd. If, against long-standing BCP recommendations, "restrict default noquery …" is not specified, a specially crafted control mode packet can set ntpd traps, providing information disclosure and DDoS amplification, and unset ntpd traps, disabling legitimate monitoring. A remote, unauthenticated, network attacker can trigger this vulnerability."

CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’) – CVE-2016-7427

According to NTP.org, "The broadcast mode of NTP is expected to only be used in a trusted network. If the broadcast network is accessible to an attacker, a potentially exploitable denial of service vulnerability in ntpd’s broadcast mode replay prevention functionality can be abused. An attacker with access to the NTP broadcast domain can periodically inject specially crafted broadcast mode NTP packets into the broadcast domain which, while being logged by ntpd, can cause ntpd to reject broadcast mode packets from legitimate NTP broadcast servers."

CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’) – CVE-2016-7428

According to NTP.org, "The broadcast mode of NTP is expected to only be used in a trusted network. If the broadcast network is accessible to an attacker, a potentially exploitable denial of service vulnerability in ntpd’s broadcast mode poll interval enforcement functionality can be abused. To limit abuse, ntpd restricts the rate at which each broadcast association will process incoming packets. ntpd will reject broadcast mode packets that arrive before the poll interval specified in the preceding broadcast packet expires. An attacker with access to the NTP broadcast domain can send specially crafted broadcast mode NTP packets to the broadcast domain which, while being logged by ntpd, will cause ntpd to reject broadcast mode packets from legitimate NTP broadcast servers."

CWE-410: Insufficient Resource Pool – CVE-2016-9312

According to NTP.org, "If a vulnerable instance of ntpd on Windows receives a crafted malicious packet that is "too big", ntpd will stop working."

CWE-20: Improper Input Validation – CVE-2016-7431

According to NTP.org, "Zero Origin timestamp problems were fixed by Bug 2945 in ntp-4.2.8p6. However, subsequent timestamp validation checks introduced a regression in the handling of some Zero origin timestamp checks."

CWE-20: Improper Input Validation – CVE-2016-7434

According to NTP.org, "If ntpd is configured to allow mrulist query requests from a server that sends a crafted malicious packet, ntpd will crash on receipt of that crafted malicious mrulist query packet."

CWE-605: Multiple Binds to the Same Port – CVE-2016-7429

According to NTP.org, "When ntpd receives a server response on a socket that corresponds to a different interface than was used for the request, the peer structure is updated to use the interface for new requests. If ntpd is running on a host with multiple interfaces in separate networks and the operating system doesn’t check source address in received packets (e.g. rp_filter on Linux is set to 0), an attacker that knows the address of the source can send a packet with spoofed source address which will cause ntpd to select wrong interface for the source and prevent it from sending new requests until the list of interfaces is refreshed, which happens on routing changes or every 5 minutes by default. If the attack is repeated often enough (once per second), ntpd will not be able to synchronize with the source."

CWE-410: Insufficient Resource Pool – CVE-2016-7426

According to NTP.org, "When ntpd is configured with rate limiting for all associations (restrict default limited in ntp.conf), the limits are applied also to responses received from its configured sources. An attacker who knows the sources (e.g., from an IPv4 refid in server response) and knows the system is (mis)configured in this way can periodically send packets with spoofed source address to keep the rate limiting activated and prevent ntpd from accepting valid responses from its sources."

CWE-682: Incorrect Calculation – CVE-2016-7433

According to NTP.org, "Bug 2085 described a condition where the root delay was included twice, causing the jitter value to be higher than expected. Due to a misinterpretation of a small-print variable in The Book, the fix for this problem was incorrect, resulting in a root distance that did not include the peer dispersion. The calculations and formulae have been reviewed and reconciled, and the code has been updated accordingly."

For more information, please see NTP.org’s security advisory.

The CVSS score below is based on CVE-2016-9312.

Impact

A remote unauthenticated attacker may be able to perform a denial of service on ntpd.

Solution

Implement BCP-38.

Use "restrict default noquery ..." in your ntp.conf file. Only allow mode 6 queries from trusted networks and hosts.

Apply an update

Upgrade to 4.2.8p9, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page.

Monitor ntpd

Properly monitor your ntpd instances, and auto-restart ntpd (without -g) if it stops running.

Vendor Information (Learn More)

Vendor Status Date Notified Date Updated
NTP Project Affected 18 Nov 2016
CoreOS Not Affected 21 Nov 2016 21 Nov 2016
ACCESS Unknown 21 Nov 2016 21 Nov 2016
Alcatel-Lucent Unknown 21 Nov 2016 21 Nov 2016
Apple Unknown 21 Nov 2016 21 Nov 2016
Arch Linux Unknown 21 Nov 2016 21 Nov 2016
Arista Networks, Inc. Unknown 21 Nov 2016 21 Nov 2016
Aruba Networks Unknown 21 Nov 2016 21 Nov 2016
AT&T Unknown 21 Nov 2016 21 Nov 2016
Avaya, Inc. Unknown 21 Nov 2016 21 Nov 2016
Barracuda Networks Unknown 21 Nov 2016 21 Nov 2016
Belkin, Inc. Unknown 21 Nov 2016 21 Nov 2016
Blue Coat Systems Unknown 21 Nov 2016 21 Nov 2016
Brocade Communication Systems Unknown 21 Nov 2016 21 Nov 2016
CA Technologies Unknown 21 Nov 2016 21 Nov 2016

If you are a vendor and your product is affected, let
us know
.
View More &raquo

CVSS Metrics (Learn More)

Group Score Vector
Base 7.8 AV:N/AC:L/Au:N/C:N/I:N/A:C
Temporal 6.1 E:POC/RL:OF/RC:C
Environmental 6.1 CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

Credit

NTP.org thanks Matthew Van Gundy of Cisco, Robert Pajak, Sharon Goldberg and Aanchal Malhotra of Boston University, Magnus Stubman, Miroslav Lichvar of Red Hat, and Brian Utterback of Oracle for reporting these vulnerabilities.

This document was written by Garret Wassermann.

Other Information

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Related: